Connector limits and scope

Connectors run other people's services on real credentials, so Vaulter puts deliberate boundaries around them: how many you can have, how fast your app may call them, how much of your account it may spend, and whose connection a call runs on. This page is the map of those boundaries, so none of them surprises you in production.

How many connectors

Connector counts follow your plan: none on Free, 3 on Starter, unlimited on Pro and Teams. The count is per workspace. If you hit the Starter cap, disconnecting a service you no longer use frees the slot.

Whose connection a call runs on

Every connected service has a connection scope, and it decides whose credential your published app spends:

• Owner-shared (the common case): your app's users all ride on your connection. Right for services where the account is the app's, not the user's: your Stripe, your Resend, your OpenAI key. You pay that provider; your users just use the feature.
• Per-user: each user of your app connects their own account, through the service's own sign-in, and calls run on their credential. Right for features like "post to your own Slack" or "read your own calendar", where acting as the user is the point.

The agent picks the scope that fits the feature, and it changes what your users experience: owner-shared features just work, per-user features start with a connect step for each user.

The spending guardrails

Three limits protect you, in order of who they defend:

• A rate limit of 60 calls per minute applies to every connector: per project while you build, per user of your app once published. A burst past it gets a clear "too many requests" answer and clears within the minute. Apps that retry in a tight loop are the usual trigger; tell the agent if you see it.
• An owner spend quota, which you set, caps how many calls a published app may make on an owner-shared connection per 30 days. When it is reached, calls stop with a payment-required error until the window moves or you raise it. If strangers on the internet can make your app call a service you pay for, set this; it turns "surprise bill" into "feature paused".
• An endpoint policy decides which operations are allowed at all. While you build, your own connection is broadly usable. On a published app spending your credential, only the operations the app actually shipped with (plus a curated safe set) are allowed, and genuinely destructive operations, like refunds, payouts, and API-key management, are blocked in every context. Those belong in the provider's own dashboard.

Approval on Teams

In a Teams workspace, connecting a service can require sign-off: an editor who tries to connect gets a pending approval state, and an owner or admin approves or declines it. Owners and admins connect directly. This keeps "who plugged what into our workspace" a deliberate decision on shared accounts.

Frequently asked

Which scope does my app use for a given service?

Think about whose account the feature needs. Sending your app's transactional email is owner-shared; posting to the user's own Slack is per-user. If the agent chose differently than you intended, say so; the scope is part of the feature, not fixed by the service.

What do my users see when a per-user connector is involved?

A connect step, once: the service's own authorization window, tied to their account in your app. After that the feature works for them without re-asking, until they disconnect.

Do connector calls cost tokens?

No. Tokens meter AI building. Connector calls are your app running, bounded by the limits on this page, and whatever the provider itself charges on the connected account.

A connector call failed with a 403 that names the endpoint

The endpoint policy declined the operation: the published app tried something outside what it shipped with. If the feature is legitimate, rebuild it through chat so it ships as a declared capability, then publish; if you did not expect the call at all, the block did its job.