# API keys > Personal keys act as you. Platform API keys act as the workspace. Each kind holds its own scopes, and neither can hold the other's. Source: https://docs.generalinput.com/api/api-keys Keys are created in the dashboard under **Settings, then API, then API keys** (`web.generalinput.com/~/settings/api-keys`). The full key is shown once, at creation. Copy it into a secret store; after that the dashboard still shows the key's name, scopes, and creation and last-used times, plus a prefix (`gi_sk_` and the first eight characters), but never the secret again. ## Two kinds of key [#two-kinds-of-key] | | Personal key | Platform API key | | ------------- | -------------------------------------------------- | ------------------------------------------------------ | | Prefix | `gi_sk_` | `gi_org_` | | Acts as | You, in the workspace it was created in | The workspace, through the member who created it | | For | A script or a CLI that should act as you | A self-hosted instance or an outside agent | | Reaches | Your workflows, skills, projects, memory, triggers | Integration docs, the vault, hosted services | | Never reaches | Docs, the vault, hosted services | Workflows, anything member-owned | | Logged as | Usage and credential access are logged against you | Usage is billed to the workspace as external API usage | | Created from | Any dashboard | The cloud dashboard only | The split is deliberate. A personal key is a member: it can build and run the things that member owns, and every credential access lands in the audit log under that member's name. A platform API key is the product API: it can read the catalog, hand out tokens from the vault, and call hosted services, but it can never start a run or touch member-owned data. A platform API key still needs someone to act as. It acts as the member who created it, so it sees the credentials that member owns or has been granted. If that member leaves the workspace, the key stops working with a `401` rather than falling back to someone else. Create platform keys from an account that will stay. Keys marked **Managed OAuth secrets** in the dashboard were provisioned by General Input for an instance that runs its own OAuth flows. No customer-created key ever carries that flag. ## Scopes [#scopes] Every `/v1` route is behind one scope. Pick the scopes a key needs when you create it; a key defaults to every scope its kind may hold. ### Platform API key scopes [#platform-api-key-scopes] | Scope | Grants | Routes | | --------------- | ---------------------------------------------------------------------------------------------------------------------- | ------------------------------------------- | | `docs:read` | Search and read the integration catalog and operation reference. | [Integration docs](/api/integrations) | | `vault:read` | See which credentials the member holds, their fields and env var names. Never secret values. | [Vault](/api/vault) | | `vault:connect` | Start a connection and get a link for a person to complete it. | [Connections](/api/vault/create-connection) | | `vault:token` | Fetch a fresh access token or API key for a credential. Every fetch is logged. Implies `vault:read`. | [Issue a token](/api/vault/issue-token) | | `platform:use` | Call hosted services: internet search, scraping, geolocation, email, images, chat completion. Billed to the workspace. | [Hosted services](/api/platform) | ### Personal key scopes [#personal-key-scopes] | Scope | Grants | Routes | | ------------------ | ---------------------------------------------------------- | --------------------------- | | `workflows:manage` | List, create, update, and run your workflows and apps. | [Workflows](/api/workflows) | | `skills:manage` | List, create, and update your skills. | [Skills](/api/skills) | | `memory:manage` | Read and propose changes to workspace and personal memory. | [Memory](/api/memory) | | `projects:manage` | List, create, and update projects and their files. | [Projects](/api/projects) | | `triggers:manage` | Inspect and configure workflow triggers. | [Triggers](/api/triggers) | There is no wildcard scope. A scope written on the wrong kind of key never grants anything: the server narrows a key to its kind's set before checking, so a personal key row that somehow carried `docs:read` still gets a `403` from the docs routes. ## Using a key [#using-a-key] ```sh curl -s https://cloud.generalinput.com/v1/credentials \ -H "Authorization: Bearer gi_org_…" ``` A `401` means the key is missing, unknown, or revoked. A `403` with `Insufficient scope` means the key is valid but was not created with the scope the route needs. Neither response says which, on purpose. ## Revoking and rotating [#revoking-and-rotating] Revoke a key from the same settings page. Revocation is immediate; in-flight requests already past authentication finish, everything after fails with `401`. To rotate, create the new key first, move callers over, then revoke the old one. Keys never expire on their own. ## Which credential should I use? [#which-credential-should-i-use] | I want to… | Use | | --------------------------------------------------------------- | ------------------------------------------------------------------ | | Let Claude Code or Codex on my laptop use my accounts | [`geni login`](/cli), not a key | | Give an outside agent a way to find operations and fetch tokens | Platform API key with `docs:read`, `vault:read`, and `vault:token` | | Call web search or image generation from my own code | Platform API key with `platform:use` | | Run my workflows and read their executions from CI | Personal key with `workflows:manage` | | Use Claude.ai or ChatGPT against the workspace | [MCP](/mcp), which uses OAuth, not a key |