Authentication

Org API keys, the Authorization header, key scopes, and the max-tier requirement.

Authentication

Every API request authenticates with an org API key using a Bearer token:

Authorization: Bearer sk_xxxxxxxx_xxxxxxxxxxxxxxxxxxxxxxxx

There are no cookies or sessions involved. A key always acts inside the single workspace it was created in.

Creating a key

Settings -> Developer -> New key (requires the DEVELOPER permission and the max plan tier).
Give it a name and pick its scopes (which resources and which of read / create / update / delete it may use).
Copy the key. The raw value is shown once and never stored - we keep only a hash. If you lose it, create a new one.

You can set an optional expiry, revoke a key (disable without deleting), or delete it. Revoked, expired, or deleted keys are rejected immediately.

What a key can do

A key acts with full authority inside its workspace, bounded by its scopes. In other words, the scopes you grant are the only limit - a key is not additionally restricted to the permissions of whoever created it. So grant the minimum scopes each integration needs, and prefer separate keys per integration.

Writes are attributed in the audit log to the workspace member who created the key.

The max-tier requirement

The Custom API is only available on the top plan:

Keys can only be created while the workspace is on the max tier.
Every request re-checks the plan. If the workspace drops below the max tier, all of its keys immediately return 403 until it upgrades again.

Scopes

Scopes are per-resource and per-action, for example leads.read or invoices.create. A request to an endpoint you have not granted returns 403 with a message naming the scope it needs. See Scopes & permissions for the full model and the resource list.