Changelog
Scoped API keys and platform keys for the General Input API
The public /v1 API now has two kinds of key with separate, explicit scopes, and every route checks exactly one. A personal key acts as you and manages your workflows, skills, memory, projects, and triggers. A platform API key, now available to every workspace, acts for the workspace: it can search the integration catalog, hand out credential tokens, and call hosted services, but can never start a run or touch members' resources. That split lets you give an outside agent, such as Claude Code, Codex, or your own, exactly the access it needs. See the developer page.
How it works
- No wildcards. Platform keys hold docs, vault, and platform scopes; personal keys hold workflow, skill, memory, project, and trigger scopes.
- Hosted services. A single endpoint reaches internet search, scraping, email, image generation, and chat completion, billed to the workspace.
- Credentials. List the credentials a key's member can use (field names, never values), or issue a fresh access token through the same audited path runs use. Refresh tokens are never returned.
- Connections. Open a pending connection that a person completes through the regular sign-in flow.
- Tied to a person. If the member who created a platform key leaves, the key stops working.
Also shipped
- A full
/v1reference in the developer docs, including scopes, errors, and rate limits.