Every request carries an API key that says which project is calling. Rules can read it, and keys themselves can be restricted.

​
The two roles

Never put a secret key in client code. See Keys and security.

​
Scopes

A key can be limited to scopes: named permissions like resource:read, resource:write, routes:invoke. A key without a scope can’t do that kind of thing even if the rule would allow it. Use the scope shorthand to require one in a rule:
  • Key has scope resource:write
or "scope:resource:write" as a reference.

​
Create restricted keys

Studio: the API keys page of the environment, then New key. Choose the role (publishable or secret), a name, scopes, an expiry, and optionally allowed addresses and allowed routes. Rotate issues a new secret and keeps the old one working for a grace period (graceHours) so you can deploy without downtime.

​
Use least privilege

  • A reporting job: a secret key with resource:read, limited to your server’s address.
  • A mobile app: the publishable key, nothing else.
  • A partner integration: a scoped secret key with an expiry and an allowed-routes list.

​
User API keys

People can create their own keys that act as them. Those are separate: see User API keys. Services and AI agents get identities of their own: see Machines and agents.

Keys and security

The basics.

Shorthands

The scope shorthand.