Developer authentication

Protected developer requests use a bearer key:

Authorization: Bearer exepad_dk_YOUR_KEY

Create your first key through the account’s developer settings. Current plan packaging includes developer access in Pro. Public pricing and A2A discovery do not need a bearer key.

Key management

Operation	Endpoint
List metadata	GET /v1/keys
Inspect metadata	GET /v1/keys/{keyId}
Create	POST /v1/keys
Rotate	POST /v1/keys/{keyId}/rotate
Revoke	DELETE /v1/keys/{keyId}

Create accepts name, scopes, apps, and optional expires_in_days. A key making a management request needs keys:write and cannot grant scopes or app pins beyond its own authority. Account sessions can also manage their own keys.

The complete secret is returned when a key is created or rotated. Metadata reads do not reveal it. Rotation creates a replacement and deactivates the old key at once: a request that still uses the old key gets 401 until you switch it to the new one. Revoking a key also takes effect at once.

Scope a first integration

For wallet and limit reads, use billing:read. MCP key inventory uses keys:read. Key management and billing changes have separate write permissions. Avoid broad wildcards for an integration that only needs a read.

App pins do not establish a current app-lifecycle endpoint, and should not be treated as limits on every account-level operation. See Scopes for the actual boundaries.