Administer

Access Keys

Authenticate your backend's requests to Agent Handler.

An Access Key authenticates your backend’s requests to the Agent Handler API and to the MCP server. Every call carries one in the Authorization header:

Authorization: Bearer <YOUR_API_KEY>

The word Bearer is required and case-sensitive. The key never appears anywhere else.

Production vs test

ProductionTest
How manyOne per organizationAny number
Environment scopeProduction Registered Users, real Connector calls, production audit logSandbox: test Registered Users, test data, separate audit log
RotatableYes, from the dashboardCreated and deleted at will
Use caseYour live backend serving real customersDevelopment, staging, CI

Test keys give you a clean sandbox. Credentials, Registered Users, and tool calls created with a test key are isolated from production. The trade-off: you can’t use a test key to call production data, and you can’t use a production key to read test resources. If you mix them up, you’ll see 404 not found on resources that you’re sure exist.

Manage both at Settings → API Keys.

Generating keys

Production key. Already exists when your account is provisioned. Click Regenerate token to rotate it. Rotation invalidates the old key immediately - propagate the new value to every backend before clicking, or you’ll have an outage as long as it takes to redeploy.

Test keys. Click + Create new key, name it (a hint about what it’s for - “ci”, “alice-dev”, “staging-2”), copy the value. The value is shown once; if you lose it, delete the key and create a new one.

Rotation

Rotate the production key at least once a year, and immediately if you suspect it leaked. The mechanics:

  1. Generate the new key. Don’t click Regenerate yet.
  2. Roll the new key out to every backend that uses it - secret manager update, release, confirm.
  3. Click Regenerate token in the dashboard. The old key stops working at the moment you click.
  4. Confirm traffic on the new key.

If a key has leaked publicly (committed to a repo, posted in a chat), regenerate first, roll out second. The cost of an outage is much lower than the cost of someone else having your key.

Allowed callback origins

OAuth callbacks from third parties (and from Link) need to redirect somewhere on your domain. That domain has to be on Agent Handler’s allow-list - a security check to stop someone else’s domain from receiving your users’ OAuth codes.

At Settings → API Keys → Allowed callback origins, add every domain that hosts your frontend. The match is exact:

  • app.example.com covers https://app.example.com/... only.
  • staging.example.com is a separate entry.
  • localhost:3000 is its own entry - add the ports you use in development.

If you skip this, OAuth callbacks fail with “unauthorized origin” and your users see a broken auth flow. See Troubleshooting → Allowed callback origin error.

Storage

Treat keys like any other secret.

  • Don’t commit them. Gitignored .env for local development; secret manager (AWS Secrets Manager, Vault, Doppler, 1Password) in deployed environments.
  • Don’t expose them client-side. Production keys authorize calls on behalf of every customer’s Registered User. Always proxy MCP calls through your backend.
  • Don’t share them across environments or services. Each environment, and ideally each service, holds its own copy.

The Audit Trail records every key creation, regeneration, and deletion. For the Context layer for employees setup, end users authenticate via OAuth through your IdP rather than an API key.

Next

Bring your own OAuth app per Connector with Application Credentials.