Your credential, your bill.

How this differs from a curated data source

There are two ways data reaches an agent here, and the difference is who holds the upstream relationship.

Curated sources are documented in the API reference, which carries the per-call pricing for each one.

One pass-through route per vendor

Every HTTP method is accepted on /v1/connections/:vendor/*. Everything after the vendor segment is appended to the vendor's own base URL, so you address the vendor's API with the vendor's own paths. The method, the query string, the JSON body and its Content-Type all ride along, and we attach the credential for you.

curl -s "https://api.superagnt.com/v1/connections/hubspot/crm/v3/objects/contacts?limit=10" \
  -H "Authorization: Bearer $AGNTDATA_API_KEY"

Authentication is Authorization: Bearer <your superagnt API key>. Keys are minted and rotated in the dashboard at app.superagnt.com.

Where the vendor ships a bundled OpenAPI spec, the request is validated against it before it leaves us. A bad parameter comes back as a 400 naming the field and where it was found, instead of as a confusing vendor error.

Two credential kinds, one catalog

Connections live on the Integrations page in the dashboard, split into Enabled (what this workspace has connected) and Available (everything else).

1. 01

   Pick the vendor

   Open Integrations in the dashboard and choose the vendor from the Available list.

2. 02

   Authorize, or paste a key

   An OAuth vendor opens a popup and you approve the install there. An API-key vendor shows a field you paste into once. Per-vendor setup notes render inline and tell you exactly where in the vendor's own settings to generate that key.

3. 03

   Done

   The vendor moves to Enabled, its REST route starts answering, and its tools appear on the workspace MCP server.

A few vendors accept either kind. When a vendor supports both and the workspace has an active OAuth install, the OAuth install wins and the pasted key is ignored.

You never handle an access token

OAuth access tokens are refreshed for you, just in time, before each call. If the vendor still answers 401, we force one refresh and retry the call exactly once. That covers the ordinary case of a token that expired mid-flight.

If the retry fails too, or the install has no refresh token, the install is marked revoked. Calls then return a 401 telling you to reconnect from the dashboard, and opening that connection in the dashboard shows a reconnect prompt naming the state it is in (revoked, expired, or needs attention). Nothing silently half-works.

What the proxy does with an upstream failure

Upstream statuses are translated into something a caller can act on, rather than passed through raw.

Failed calls are logged at zero cost, same as successful ones. A broken connection never costs you credits.

Connecting a vendor is the opt-in

Each vendor operation is also an MCP tool named connection_<vendor>_<operationId>. Curated data sources are on by default on a grouped server, which every workspace server is unless it was set up per operation, and a per-operation server switches them on family by family. A connection skips that step on every server: the moment the account is connected, its family (connection:<vendor>) joins the default server's always-on base and its tools show up. Disconnect it and they go away again.

A deployed agent that calls a connection tool for a vendor the workspace has not connected gets a structured tool result rather than a protocol error, carrying a dashboard link it can hand to a human:

{
  "code": "INTEGRATION_NOT_CONNECTED",
  "error": "INTEGRATION_NOT_CONNECTED",
  "vendor": "hubspot",
  "connect_url": "https://app.superagnt.com/dashboard/<workspace-id>/connections/hubspot"
}

Synced vendors

Some vendors (Cal.com, HeyReach, Smartlead, EmailBison, Calendly, lemlist, RB2B, Apollo, La Growth Machine, Expandi, Instantly) can also be synced: their data is copied into tables in your workspace database and kept fresh, so an agent reads local tables instead of paging the vendor on every run. Turn it on from the Sync panel on the vendor's connection page, or with agnt_sync_enable. The connection tools keep working alongside it. See Vendor sync.

Two different ceilings

The limit that produces a 429 from us is your plan's requests-per-minute figure, counted per workspace across every /v1 surface — see Errors and rate limits.

Separately, the integration registry records the ceiling each vendor declares for its own API, chosen to sit under what the vendor allows. The proxy does not throttle against these figures; they are published so you can size a burst of agent calls before the vendor's own limiter does it for you, with a 429 that is theirs rather than ours.