Where to manage keys
Open the Developer Dashboard — you can also reach it from Settings → API Keys, which redirects. The dashboard lists every key you’ve created with its name, creation date, last-used time, and capability set.Free tier cannot create usable keys — Free’s API key ceiling is empty. The dashboard shows an “API access requires Pro” upgrade CTA instead of the create-key form. Upgrade to Pro to unlock external API access.
Create a key
Click Create Key
Pick a name that identifies where the key will be used — for example,
github-actions-deploy or mobile-app-production.Pick a preset (or Custom)
The CapabilitySelector offers four presets that cover the common cases:
Capability options grayed out under Custom are above your tier’s ceiling. Free tier has zero options. Pro can grant
| Preset | Capabilities | Use for |
|---|---|---|
| Read-only | workflow:read | Audit / monitoring / dashboards that only inspect |
| Workflow Deploy | workflow:run + workflow:read | Running deployed workflows from a CI/server |
| Webhook receiver | webhook:receive | Receiving outbound webhook deliveries (?async=true flow) |
| Full deploy | workflow:run + workflow:read + workflow:write | Full programmatic control of your workflows |
| Custom | (granular) | Pick exact capabilities — locked-flow keys via workflow:<slug>:run, locked-model keys via model:<id>:run, etc. |
workflow:* + webhook:receive. Business+ adds model:* and agent:invoke.Capabilities
Capabilities are orthogonal, not cumulative. A key withmodel:run does NOT automatically get workflow:write. Grant exactly what your integration needs.
| Capability | What it admits |
|---|---|
workflow:run | POST /api/workflows/:slug/run (any of your workflows) |
workflow:<slug>:run | POST /api/workflows/<slug>/run (specific slug only) |
workflow:read | GET /api/workflows, :slug, :slug/schema |
workflow:write | POST/PUT/DELETE /api/workflows (ownership-checked) |
model:run | POST /api/models/:internalName/run (any registry model — Business+) |
model:<id>:run | POST /api/models/<id>/run (specific model only) |
webhook:receive | Receive outbound webhook deliveries |
execution:read | GET /api/executions/:id (poll) |
execution:cancel | POST /api/executions/:id/cancel |
agent:invoke | (reserved for SSE / streaming, not yet shipped) |
workflow:* matches workflow:run) → general-implies-specific (workflow:run admits workflow:my-flow:run) → pattern admission (workflow:*:run admits any per-flow check). See API Reference → Authentication for the full rule.
Per-flow and per-model keys (least-privilege)
Use Custom mode to lock a key to ONE workflow or ONE model:- A key with
workflow:my-thumbnail-pipeline:runcan ONLY run that specific flow. Calling/api/workflows/anything-else/runreturns403 CAPABILITY_DENIED. Perfect for embedding in a single integration where one webhook URL = one key = one workflow scope. - A key with
model:gpt-image-2:runcan ONLY invoke that one model. Useful for CI keys that should never accidentally run an expensive video model.
Store keys safely
- Use a secrets manager (1Password, AWS Secrets Manager, Vercel env vars). Never commit keys to git.
- Don’t paste keys into chat tools, screenshots, or shared Slack channels.
- Set a calendar reminder to rotate keys every 90 days for high-traffic integrations.
- If a key is compromised, revoke it immediately from the Developer Dashboard.
Revoke a key
In the Developer Dashboard, find the key and click Revoke. Revocation is immediate — subsequent requests using that key return401 Unauthorized. There is no grace period; deploy a replacement key first if you need to swap without downtime.
Pre-Phase-11 keys
Keys created before May 2026 (the Phase 11 capability cutover) were retired by the migration. Any request using one returns401 LEGACY_KEY_RETIRED. See Migration from scopes for the mapping from old scopes to equivalent capability bundles.