API keys

crab key create ci --scope deployments:write --scope services:write --days 90

• Make one under Settings → API keys → Create key, an org's settings for its owners, or with crab key create <label>. Set a daily budget and expiry, then choose None, Read or Write for each resource under Permissions and allow priced services under Services. Its token is shown once, starts with ck_ and is stored only as a hash.
• --days sets when it expires; by default it never does. --scope replaces the default permissions; repeat it for each scope. --no-scopes creates a key with no management permissions.
• crab key ls lists the account's keys, active and revoked. Settings → API keys lists the active ones with what each may do, its spend today, when it was last used and when it expires; use each row's more menu to Edit or Revoke. Edit keeps budget, permissions and service changes pending until you select Apply changes; they are saved together.
• Revoking one, in Settings or with crab key rm <id>, stops it at once. To replace a key, create a new one, update the agent or script using it, then revoke the old one.
• Make one key per agent or script, so one can be revoked without the rest. MCP OAuth and crab login --device create a dedicated key automatically after browser approval; review its name, permissions and budget on that page, then manage it with your other keys.
• crab context add <name> https://api.crabtalk.ai --token-stdin --org <org> makes a context that uses one. See Contexts.

What a key does

• It acts as the person who made it, on the account it was made on.
• New keys default to services:read, deployments:read, calls:read, and usage:read. Clear any of these before creation or change them afterward. Existing keys do not receive new defaults.
• Each resource:write permission includes resource:read for the same resource. Read does not grant write access. Organization permissions apply only to the organization the key belongs to, and the creator's role is checked on each request.
• deployments:write permits direct deploys with --yes. Explicit service settings and price changes also require services:write. --yes deploys all services or rolls the set back; page-approved deploys keep successful services live and report failures separately. Required secrets must be set before direct deployment.
• Any key can submit an approval request for its own account and follow the request at its link. Approval runs that operation as the approving owner and does not change the key's permissions. Other pending requests remain valid.
• It calls that account's services, private ones included, and every public service's public tools. A call needs no management scope. Another account's priced tool takes a grant, below.
• Keys cannot delete resources, remove memberships, or revoke invitations. Account profile lookups (GET /users/{user} and GET /orgs/{org}), key creation and permission changes, organization creation, personal identity and security settings, and payment actions require a session.
• secrets:read lists account-owned secret resource names, IDs and service grants. Values are never returned. Creating, rotating or deleting these resources and changing grants require a session.
• Secret destinations and static schedules come from the deployed manifest. services:read permits inspecting their metadata. Keys cannot provision or revoke secret values; a signed-in owner supplies them through a credential or deployment request.
• Legacy deploy and auto keys migrate to explicit service permissions. Deletion is removed; billing reports require an explicit billing:read grant.
• Deleting an org revokes its keys.

Management permissions

See Management scopes for the complete permission table and Operations for actions that require a session.

Keys on the same account share its request limits, including the execution quota shared by REST and MCP. Creating another key does not add allowance.

Priced services and a daily budget

crab key ask --service acme/enrich --budget 20

• A key calls another account's priced service once it holds a grant for it. Without one the call is refused with E0009, and the refusal carries a link to a grant request asking for it.
• A key spends at most its budget on tool prices in a UTC day: $5 unless an owner sets another. Calls held count. A call past it is refused with E0010, and the refusal links to a grant request asking for twice the budget, or what the call needs when that is more.
• An owner of the account approves a grant request signed in, at its link. crab request <code> --wait returns once they do. A key holds one pending grant request; each refusal and each crab key ask adds to it.
• crab key ask asks ahead, with the key crab signs in with: --service <owner>/<name> for each service, --budget in USD a day.
• An owner grants and sets these directly, on the key's page in Settings or with crab key grant <id> <owner>/<name>, crab key ungrant <id> <owner>/<name> and crab key budget <id> <usd>. A key's page also shows its waiting grant request, to approve or decline there.
• A grant ends when its service is removed.