Vercel Connect

Vercel Connect lets your agents and services act on third-party APIs on behalf of your users and teams. Instead of storing provider credentials in long-lived environment variables, you register a connector for the provider and request short-lived tokens at runtime, scoped per project and per environment.

Use Vercel Connect to:

• Call third-party APIs from an agent: Post to Slack, open GitHub PRs, query Snowflake, or hit any OAuth- or API-key-protected service without bundling provider secrets into your deployment.
• Act on behalf of your users: Ask a user to authorize once and obtain a refreshable user token that your agent can use to make calls as that user.
• Receive provider webhooks: Verify and forward signed Slack events to project destinations you control.

To create your first connector and request a token, follow the Quickstart. For the conceptual model, see the Concepts overview — start with Connectors, Tokens, and Authentication.

Vercel Connect authenticates in two directions on each token request: from your code to Vercel Connect, and from Vercel Connect to the provider.

The @vercel/connect SDK supports two authentication methods:

• Vercel OIDC token (recommended): On Vercel, the SDK uses the OIDC token that Vercel injects into your deployment automatically. Connect verifies the token and checks it against the connector's project links to confirm the project and environment are allowed to request tokens.
• Access token: For external CI/CD or non-Vercel environments where VERCEL_OIDC_TOKEN isn't available, pass a Vercel access token to the SDK via the vercelToken option on getToken. Dashboard and CLI calls authenticate the same way, using your active Vercel session.

For the local-development setup that pulls an OIDC token into .env.local, follow the Quickstart.

Each connector type has its own provider-side flow:

• Slack and GitHub: Managed app installs, scoped to one workspace or organization per installation.
• Custom OAuth: Managed OAuth against the service's URL, on behalf of the installing user.
• API key: A credential the connector owner supplies once at create time.

For the full picture, including how token requests are authorized against project links, RBAC for dashboard and CLI calls, the per-connector provider flows, and the error classes thrown on auth failures, see Concepts: Authentication.

• Multiple connector types: Built-in support for Slack, GitHub, Snowflake, Salesforce, API-key, and Custom OAuth.
• Token subject types: One connector can issue tokens that act as your service (app), a specific user (user), or a federated identity (jwt-bearer).
• Installations and multi-tenancy: One connector serves many tenants, such as Slack workspaces or GitHub organizations.
• Fine-grained scoping: Narrow each token with provider scopes, resource indicators, and rich authorization requests.
• Refresh and revocation: Tokens refresh automatically; revoke at the provider when supported.
• Trigger forwarding: Verified webhooks fan out to the project destinations you register on the connector.
• Connector branding: Per-connector icon, background color, and accent color.

• SDK Reference: API reference for @vercel/connect, including getToken, getTokenResponse, the ConnectTokenParams and ConnectTokenResponse shapes, and the error classes.
• CLI Reference: Manage connectors, project links, and triggers from the terminal with vercel connect.

Vercel Connect supports two operating models, defined in the Vercel Connect product terms. The model determines who registers the OAuth client (or credential) with the Third Party Platform and what setup work falls to you.

Vercel registers the OAuth client with the Third Party Platform and you authorize Vercel's client to access your account or workspace. You do not register an OAuth client or manage client secrets. See Section 3 of the Vercel Connect terms.

• Slack: Vercel-developed Slack app, installed per workspace.
• GitHub: Vercel-developed GitHub app, installed per organization or user.
• Snowflake: Snowflake Partner Connect integration.
• Salesforce: Vercel-managed OAuth client against your Salesforce org.

You register an OAuth client (or generate an API key) with the Third Party Platform yourself and supply the credentials at create time. Vercel stores them and exchanges tokens on your behalf at runtime. You are responsible for managing those credentials on the provider side.

• Custom OAuth: OAuth 2.0 / OIDC authorization-code flow with PKCE against any service URL you provide. Bring your own client ID and client secret.
• API key: Static credential storage for providers that issue long-lived API keys. You supply the key at create time.

For providers that support it, Vercel Assisted Setup is a one-off helper action that performs some or all of the OAuth-client registration steps on your behalf when bootstrapping a Customer Managed Connector.

The capability matrix for each connector type, including which support installations and triggers, is on the Connectors reference page.

Vercel Connect is billed per token request. Hobby includes 5,000 token requests per month at no extra charge; Pro and Enterprise are $3 per 10,000 token requests. See Pricing and Limits for the full table, how to stop being billed, and the platform limits that apply during beta.

Use Vercel Connect when you need delegated runtime credentials, when the same provider serves multiple Vercel projects or environments, or when an agent needs to act on behalf of a user. Use a Vercel Integration instead when you want a marketplace-managed install for a provider-billed product.