Vercel SDK

@vercel/sdk is the official TypeScript client for the Vercel REST API, generated end-to-end by Speakeasy from Vercel’s OpenAPI specification. Instead of hand-writing HTTP calls and response typings, the SDK exposes a single Vercel client whose namespaced resources — projects, deployments, domains, dns, aliases, certs, environment, teams, and dozens more — mirror the full surface of the platform’s API, each with fully typed request/response models validated at runtime with Zod.

Because the entire package is generated directly from the spec, it stays in lockstep with the live API: new endpoints, fields, and deprecations show up as SDK updates (the repo ships near-daily releases) rather than requiring manual maintenance. Every operation returns a typed Result that distinguishes expected API error responses from transport failures (connection errors, timeouts, validation errors), and the client supports configurable retry/backoff strategies, custom fetch implementations, and both class-based and standalone tree-shakeable function usage.

It’s aimed at teams automating Vercel itself — provisioning projects and environments, managing domains and DNS records, wiring up CI/CD or internal tooling, or building on Vercel’s newer platform features like the AI Gateway, Sandboxes, and micro-frontends — anywhere a script or service needs to drive Vercel programmatically instead of through the dashboard.

What You Get

• A single Vercel client instance, authenticated with a bearer token, exposing 50+ resource namespaces (Projects, Deployments, Domains, Dns, Aliases, Certs, Environment, Teams, Sandboxes, AiGateway, and more) as typed methods
• Fully generated TypeScript types and Zod schemas for every request body and response, kept in sync with Vercel’s OpenAPI spec on every release
• Typed error handling that distinguishes API error responses (403/429/500 payloads) from transport-level failures (connection errors, timeouts, validation errors) via a Result type
• Configurable retry/backoff strategy per request or globally, plus support for a custom fetch implementation for non-standard runtimes
• Standalone, tree-shakeable functions (src/funcs/*) in addition to the namespaced client, for bundle-size-sensitive consumers
• Published as ESM-only with generated per-resource documentation (docs/sdks/*) and runnable usage examples for common operations

Common Use Cases

• Provisioning and configuring Vercel projects (env vars, domains, protection bypass) from infrastructure-as-code or internal admin tooling
• Automating deployment and alias management as part of a custom CI/CD pipeline outside Vercel’s built-in Git integration
• Managing DNS records and domain/cert lifecycles programmatically for platforms that provision customer subdomains on Vercel
• Building internal dashboards or Slack/CLI tools that surface deployment status, logs, or observability data from the Vercel API
• Configuring AI Gateway rules, feature flags, or micro-frontends definitions as part of an automated release process

Under The Hood

Architecture The SDK is generated in three layers: a thin Vercel/VercelCore client (src/core.ts, src/sdk/sdk.ts) that exposes namespaced resource classes (src/sdk/*.ts — Projects, Deployments, Domains, and dozens more), each delegating to a standalone operation function in src/funcs/*.ts (one file per API operation), which in turn calls a shared HTTPClient (src/lib/http.ts) and validates the response against a per-operation Zod schema in src/models/*.ts. Cross-cutting concerns — retries (src/lib/retries.ts), security/auth (src/lib/security.ts), URL templating (src/lib/url.ts), and error normalization (src/lib/schemas.ts) — live in src/lib and are shared by every generated function, so the whole surface behaves consistently even though it is mechanically produced rather than hand-designed; changing the core HTTPClient or retry strategy propagates to all resources at once.

Tech Stack Written in TypeScript, built with tsgo (TypeScript’s experimental native-preview compiler) and linted with oxlint. Runtime validation runs on Zod, with the package.json declaring peer support for both Zod v3 and v4. The package is published ESM-only ("type": "module") with conditional exports mapping source, types, and build output, and ships no HTTP library of its own — it wraps the platform’s native fetch, with an injectable Fetcher for non-standard runtimes. The whole repo is driven by Speakeasy’s codegen tooling from a 10MB vercel-spec.json OpenAPI document, with generation and publishing handled by dedicated GitHub Actions workflows (sdk_generation.yaml, sdk_publish.yaml).

Code Quality No unit test files exist in the repository itself; contract/compatibility testing is delegated to Speakeasy’s own reusable sdk-test GitHub Actions workflow rather than an in-repo test suite, so quality assurance for this package is external and not independently verifiable from the source. Error handling is extensive and explicitly typed: every operation returns a discriminated Result covering documented API error response bodies plus distinct ConnectionError, RequestTimeoutError, ResponseValidationError, and SDKValidationError classes, so failures are never silently swallowed. Naming is fully consistent across the 401 generated function files, and oxlint runs with --max-warnings=0, though several rules (no-explicit-any, no-unused-vars) are disabled in .oxlintrc.json to accommodate generated code patterns.

What Makes It Unique The SDK’s distinguishing trait is that it is not hand-maintained at all — it is regenerated directly from Vercel’s own OpenAPI specification on a near-daily cadence, so new endpoints, fields, and platform features (AI Gateway, Sandboxes, micro-frontends) appear as routine version bumps rather than manual client updates. This trades hand-crafted ergonomics for guaranteed spec fidelity: the typed Result/error-union pattern and per-operation Zod validation are standard Speakeasy-generated conventions rather than something unique to this project, but the tight coupling to Vercel’s actual API surface is a genuine advantage for anyone automating the platform.