API keys

An API key is a long-lived credential for your own servers. It belongs to the organisation, not to the member who made it, so it keeps working when that member leaves.

Authorization: Bearer fo_rk_live_…

Kinds and prefixesCopy Anchor Link

A key says two things in its prefix: secret or restricted, and live or test.

Prefer restricted keys: give each integration its own key with only what it needs. Restricted keys are a plan feature (restricted_keys); without it, only secret keys can be made and the wizard says so.

The formatCopy Anchor Link

After the prefix come 43 base62 characters (256 random bits), then a 6-character base62 CRC-32 checksum of everything before it, the same scheme as GitHub's tokens:

• a mistyped or truncated key is refused before any lookup, so a typo costs nothing and tells a guesser nothing;
• secret scanners can recognise a FurniOps key with almost no false positives.

FurniOps stores only a key's SHA-256. The key is shown once, when it is made or rotated; afterwards the dashboard shows its prefix and last four characters (fo_rk_live_…a9Zq).

Create a keyCopy Anchor Link

Keys are made in the dashboard, under Developers › API keys, in the mode the dashboard is in (switch to test mode for a test key). A key can never create another key, so no API call makes one.

Making, rotating and approving keys, and changing an access policy, need a sign-in within the last 10 minutes. If yours is older, the dashboard asks you to confirm it is you, then brings you back to the same screen.

ScopesCopy Anchor Link

A permission is <resource>:<action>. Every operation in the API reference lists the scopes it needs; a key without them gets 403 permission_denied. These are every permission a key can hold, with the operations that need each:

• A secret key holds all of them, and any added later.
• A restricted key holds its list for life. Its permissions never change: make a new key to change them.
• No key can ever hold api_keys:write, oauth_apps:write, members:write, org:write, billing:write, agent:write, sso:read or sso:write. Those stay with signed-in people.

TemplatesCopy Anchor Link

The wizard's presets. A key records the template it was made from.

A storefront that mirrors the catalogue needs the catalogue reads and events:read, not sources:write. A sync job that only follows the change feed needs Change feed reader.

Access policiesCopy Anchor Link

An access policy is a named list of IPv4 and IPv6 addresses and CIDR ranges (203.0.113.0/24, 2001:db8::/32). A key that holds one works only from those addresses; from anywhere else it is refused with 401 authentication_required.

• Up to 50 entries a policy, and 50 policies an organisation. One policy can be shared by any number of keys.
• A bare address means just that address. A range must be written as its network address, and /0 is refused: a key that may be used from anywhere simply has no policy.
• Policies are managed on the same page, under Access policies. Changing one reaches every key holding it within a minute.
• A policy that a usable key holds cannot be deleted. Detach it from its keys (or revoke them) first, so no key is ever silently opened to every address.

Rotate a keyCopy Anchor Link

Rotating issues a replacement with the same permissions, policy and lifetime length, and keeps the old key working for an overlap you choose: end it now, 1 hour, 24 hours, 3 days or 7 days in the dashboard (any whole number of hours from 0 to 168 through identity). Deploy the replacement within the overlap and the switch has no downtime.

• You must hold every permission the key holds to rotate it.
• A key that was already rotated cannot be rotated again; rotate its replacement.

Revoke a keyCopy Anchor Link

Revoking stops a key within a minute, for anything still using it. It cannot be undone, and the key's open reviews close.

Keys for AI agentsCopy Anchor Link

A key whose purpose is An AI agent is always restricted. Two things set it apart:

• Approval. When the organisation requires agent key approval, an agent key that can write starts pending: it does not work until another member, holding every permission it holds, approves it under Keys waiting for approval. A pending key nobody approves expires after 7 days. A key that only reads needs no approval.
• MCP writes. On the MCP server, only keys made for an agent are offered write tools. A key made for an integration or a third party gets read tools only, so a sync key can never be driven by a model.

Agent key approval is an organisation setting (agent_key_approval: off by default, or required) that only an owner can change, under Settings › Security › Organisation policies (see Organisation policies).

Suspicious-activity reviewsCopy Anchor Link

FurniOps watches where each key is used from and how its requests fare, and opens a review under Key reviews for the members who manage keys (owners, admins and developers):

A review keeps its 20 most recent observations (the country, network and /24 or /48 the use came from; the hour of a spike). Owners and the key's creator are emailed when one opens.

• If the activity is expected, dismiss it with an optional reason ("Our new CI runners"). The same thing happening again opens a new review.
• If it is not, rotate or revoke the key. Revoking closes its reviews.

A key reported as published is revoked at once by default, and the owners are emailed either way. An organisation can choose a review instead (leaked_key_action: revoke or review), an owner's choice under Settings › Security › Organisation policies (Leaked keys).

LimitsCopy Anchor Link

If a key leaksCopy Anchor Link

1. Revoke it, or rotate it with an overlap of 0, straight away.
2. Deploy the replacement.
3. Read what it did: filter the audit log and the request logs by the key's ID (key_…).

Because no key can create keys, change members or change the organisation, revoking it ends the exposure.