API keys are the credentials for the Customer API. This
page covers the dashboard side: minting, watching, and revoking keys at
/api-keys. For how a key is sent on requests — token format, scope
behavior, rotation — see authentication.
The same keys authenticate the MCP server, which lets AI tools work with your instance. A key's scopes decide which MCP tools it can use, so scope a key the same careful way whether it drives the API or an AI tool. Most MCP tools read; seven can write, and a key without write scopes cannot reach them at all — which is what makes a read-only key the right choice for exploratory AI work.
Key types
| Type | Reach | Who can mint |
|---|---|---|
| Organization | One bound organization only | Org admins of the bound organization (and instance owners) |
| Instance | Any organization, plus instance-level surfaces like users and instance settings | Instance owners only |
Prefer organization keys. An integration that serves one customer should hold a key that physically cannot read another customer's data.
Creating a key
Choose Create API key and set:
- Name — what the key is called in the list, like "Production sync" or "Salesforce integration".
- Scope — organization (pick which) or instance.
- Environment — live (
fs_live_…) or test (fs_test_…). The split is cosmetic in v1: both hit the same database. Use the prefix to keep test scripts from accidentally calling a live key. - Scopes — a read and write checkbox per resource: instance, users, organizations, forms, records, data sources, webhooks, and reports. Grant only what the integration needs; a read-only reporting job needs no write scopes at all.
- Rate limit override — optional requests-per-minute for this key, any positive number (the dashboard form suggests up to 10,000). Leave blank to use the workspace default. See rate limiting.
The token is shown once
After creation, the full token appears one time. Copy it into a secret manager before leaving the page — only the SHA-256 hash of the token is stored, so it cannot be displayed again. If you lose it, mint a new key and revoke the old one. The list afterward shows only the prefix.
Watching keys
The key list shows each key's status — Active, Revoked, or
Expired — along with when it was last used. A last_used_at that
stops moving is the signal that an integration has switched off a key
and the old one is safe to revoke.
Expiry
A key with an expiry date stops working after that time and shows as Expired. The dashboard creation form does not set an expiry yet, so keys you mint here keep working until revoked.
Revoking a key
Revocation is permanent and takes effect immediately — subsequent
requests return 401. Revoked keys stay visible in the list for audit.
Keys are immutable after creation, so changing a name, scopes, or rate
limit means minting a replacement and revoking the original; the
rotation steps walk through doing that
without downtime.