@vorel/sdk is a TypeScript client wrapping the /api/v1/* surface. Native fetch only (no axios / undici / node-fetch). Works on Node 18+ (where global fetch is GA) and the browser.
Integration path today: the REST API + live OpenAPI spec.
@vorel/sdk exists as a
fully-typed client, but it is not yet published to a public package registry; a published
@vorel/sdk is on the roadmap. Until it lands, integrate against the REST endpoints directly
(see API introduction) or generate a typed client from the
live OpenAPI spec. The TypeScript shapes below
document the client’s surface so a generated or hand-rolled client can match it.openapi-generator, oazapfts, or your tooling of choice.
Client surface
Zero runtime dependencies. The client is small enough to drop into a Lambda / Cloudflare Worker without bundling concerns. Once published, you’ll initialise it like this:Initialise the client
Resources
The client exposes 6 resource clients, one per public-API resource:list(opts?) returning a typed ApiPage<T>, and iterate(opts?) returning
an async iterator that auto-paginates.
Listing + auto-pagination
iterate() hides cursor management. Break out of the loop early and the iterator stops fetching
further pages.
Mutations
Every write resource takes a typed input shape:PATCH calls are strict-partial: pass only the fields you want to change. JSONB attribute
fields (leads.attributes, offerings.attributes) are shallow-merged server-side, with null
deleting the key.
Error handling
The SDK exposes 4 typed error subclasses, all extendingVorelApiError:
requestUrl so you can trace which call failed without rebuilding the URL.
VorelRateLimitedError.retryAfterSeconds parses the Retry-After header for you (returns null
when the header is missing or malformed).
Scheduled workflows in plain Node
The SDK is shaped for workflows that run alongside the agent rather than inside it:OpenAPI spec for non-TypeScript languages
The full OpenAPI 3.1 spec is live at:SDK versioning
@vorel/sdk tracks the public-API surface. Breaking changes to the API are version-bumped
(/v1 → /v2) before they ship; the SDK pins to the API version it targets via the User-Agent
header (@vorel/sdk/0.1.0). The current SDK targets /v1.
What’s NOT in the SDK today
- Resource-level retry loops. The SDK throws typed errors; you implement retry policy per integration (it’s hard to retry generally without knowing the integration’s idempotency story). For pagination, the iterator handles cursor management but won’t retry inside a single page on a transient 5xx.
- Streaming endpoints. Every endpoint today is request/response JSON; no streaming methods on the client.
- Webhook signature verification helper. The verification logic is a 3-line HMAC-SHA256 hex compare, easier to write inline than to import. See Webhooks for the canonical snippet.
- Webhook ingestion handler. No “build a Vorel webhook listener” framework adapter; the signature-verify + idempotency-on-id pattern is small enough to write per-integration.
Related docs
- API introduction: surface overview
- Authentication: issuing keys + scopes
- Webhooks: outbound webhook contract
- Triggers: act on the same events without writing an integration
- MCP: connect an AI client instead of writing code
