Provider account access

Connections

Connections let Pulse code call supported providers through configured account authorization without exposing tokens to browser code.

Provider connection guide for Vibecodr Pulse integrations.

Implementation focus

Use this when a backend action should run through a connected account rather than one shared app secret.

Expected outcomes

Connections are user-authorized providers

Secrets and connections solve different problems. Use a secret when the app owns a shared credential. Use a connection when an upstream action should run through a connected account or provider authorization.

Pulse code uses `env.connections` so tokens stay out of creator source, browser runtime, public logs, and viewer responses. The handler should ask for the provider action it needs, not expose the token itself.

  • Use secrets for shared app credentials such as one API key.
  • Use connected account flows when work should happen on behalf of a provider account.
  • Name provider availability honestly; not every provider is available everywhere.
  • Keep tokens out of request payloads, responses, and public source.

Configure before calling

A Pulse that calls a connected provider should fail clearly when the connection is missing, expired, or not authorized for the requested action. The vibe should render a safe app-level message and give the owner a setup path.

Do not downgrade a missing connection into a browser-side token prompt. The whole point of connections is to keep provider authorization on the trusted side of the boundary.

  • Check connection setup before publishing a route that depends on it.
  • Handle missing connection errors as setup work.
  • Use owner-visible logs for provider diagnostics.

Example and read next

Example: a Pulse should create an issue in a user's provider account. Configure a connected account, call through env.connections, and never send provider tokens to the browser.

Use these related pages when you need the next layer of guidance. They point to the most likely follow-up tasks, not every page that happens to touch the same system.

Related documentation