Vercel Connect holds the credential for a third-party service such as Slack, GitHub or Microsoft at the team level, and your code asks for a short-lived, scoped token at the moment it needs one, so no provider secret sits in your environment variables. It authenticates your deployment with Vercel's own OIDC token and refreshes provider tokens for you. We run Slack for Atlas, the agent inside Monogram Tools, through Vercel Connect, and the app holds no Slack bot token or signing secret anywhere.

What is Vercel Connect?

Connect is a broker between your Vercel projects and the services they call. You create a connector once for a provider, link it to the projects and environments allowed to use it, and install it into the workspace or organization it should act in. At runtime your code calls getToken() from @vercel/connect with the connector and a subject, and Connect returns a provider token scoped to that request.

It went generally available on Aug 25, 2026. We adopted it during the beta, as we built Atlas on eve, Vercel's agent framework, whose Slack channel takes its credentials from Connect.

Why not just store the Slack bot token in an environment variable?

You can, and plenty of apps do. The cost shows up later. A long-lived bot token in an environment variable is copied into every environment, every developer's .env.local and every CI secret store that needs it, and rotating it means finding all of those copies. The inbound side carries a second secret, the signing secret your app uses to verify that a webhook came from Slack.

Connect moves both out of the app. In Monogram Tools the Slack bot token and the inbound webhook verification live in Connect, and the absence of either from our environment is a written rule in the project, not a happy accident. The eve Slack channel takes its credentials from Connect through the @vercel/connect/eve adapter. The agent code never stores a Slack secret; when it calls the Slack API directly, it asks Connect for the current bot token and uses it for that call.

What runs through Connect in our build?

More than the agent. Atlas answers @mentions and direct messages in Slack, replies in threads with the context since it last spoke, and renders approval prompts as Slack buttons when a draft needs a person to sign off. The app around it sends to Slack too. Projects reminders go to Slack when the workspace is connected and fall back to email when it is not, campaign steps can post to a channel, and links to recorded clips unfurl into previews in Slack. Every one of those sends fetches its token from Connect.

How do installations work for a multi-tenant app?

A connector can have many installations, one per Slack workspace, GitHub organization or Microsoft tenant, and getToken() takes an installationId to say which one. Monogram Tools serves client workspaces as well as our own, so when a client connects its own Slack, the app's outbound messages for that workspace are sent with a token from that workspace's installation.

Three details from building this are worth knowing. The @vercel/connect SDK caches tokens in process and refreshes them as they near expiry, so we cache only which installation a workspace points at, never the token; a second cache would just be one more thing to keep in step. Installs can start from the Vercel dashboard or from your own code with experimental_startInstallation. Our app validates the installation id it is given by asking Connect for a real token with it, so a wrong id fails at save time instead of on the next message.

Connect vs Nango vs storing OAuth tokens yourself

These solve overlapping problems at different layers, and they are not mutually exclusive.

Storing tokens yourself: Fine for one provider, one workspace and an app that will never grow a second environment. You own the refresh flow, the encrypted storage and the rotation.
Vercel Connect: The fit when your code already runs on Vercel. Authentication to Connect is the deployment's OIDC token, so there is no Connect key to store either, and access is scoped to linked projects and environments. Billing is per token request and per trigger. Hobby includes 500 token requests and 1,000 triggers a month; Pro is $3 per 1,000 token requests and $0.95 per 1,000 triggers, at the time of writing.
Nango: A source-available, self-hostable integration platform with a far larger catalog of APIs and its own runtime for integration code. Connect lists Nango as a connector, so a team can keep Nango for integrations and still fetch Nango's credential through Connect.

If your agents and apps live on Vercel and the providers you need are in Connect's catalog, we would start with Connect. If you need hundreds of APIs or self-hosting, or you run outside Vercel, Nango or a similar platform is the better base.

App tokens or user tokens?

Connect issues tokens for different subjects from one connector. An app subject acts as your service, such as a bot posting to a channel. A user subject acts as a specific person; until that person authorizes the connector, a token request fails with an error that tells your app to send them through authorization. A jwt-bearer subject exchanges a trusted external JWT for a provider token. Atlas uses an app token, so it speaks as itself.

Where Connect stops

Revocation depends on the provider. Connect calls the provider's revocation endpoint when one exists; when it does not, the provider credential can keep working until it expires.

FAQ

Is Vercel Connect generally available?

Yes, since Aug 25, 2026, on all plans.

Do I have to refresh tokens myself?

No. Connect drives the provider's refresh flow, and the SDK caches tokens in process and fetches a fresh one as expiry approaches.

Can I use Connect outside Vercel?

Yes, by passing a Vercel access token to the SDK instead of relying on the deployment's OIDC token.

Can Connect receive webhooks?

Yes. Triggers verify provider events and forward them to destinations you register, so your app does not hold the webhook secret. Triggers are billed per destination that receives an event, and as one trigger per event when no destination is set.

What does Monogram use Connect for?

Slack, for Atlas and for the notifications Monogram Tools sends.

We design and ship agent systems for clients on this stack; see Agentic AI, Slack and Vercel.

Vendor references: Vercel Connect, Tokens, GA announcement, Pricing, Nango connector.