Skip to main content
@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.
For non-TypeScript languages, generate a client from the live OpenAPI spec via 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

Construction options:

Resources

The client exposes 6 resource clients, one per public-API resource:
Each resource has 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 extending VorelApiError:
Every error carries 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:
Before building this, check whether a trigger rule already does it. The trigger engine acts on the same events without you running a scheduler.

OpenAPI spec for non-TypeScript languages

The full OpenAPI 3.1 spec is live at:
Generate clients in any language via:
Vorel doesn’t ship language-specific SDKs beyond TypeScript today; the OpenAPI spec is the path for any other language.

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.