Can multiple people use the same API key?

Yes, several people or services can send the same API key: the server checks the key, not who is holding it. But everything attached to the key is then shared, including its rate limit, its usage record, and its revocation, and nobody can tell the callers apart afterwards. The safer pattern is one key per person or service.

On Sume, a key is a workspace credential rather than a personal login: Sume resolves the workspace, owner, and key metadata from the key itself. Facts below come from Authentication, Generation admission, and Create a run, read on 2026-09-27, plus current dashboard and API code where noted. How keys, scopes, and hosts work in general is in How Sume API keys work.

What do people share when they use one key?

Separate keys split some things and not others. On Sume, API keys and spend resolve to a workspace, so a second key in the same workspace draws on the same money and the same generation capacity.

Is it safe to share an API key?

Only as safe as the least careful person holding it. A Sume key spends your credits, and anyone holding it can run any Format you own, up to your caps. You can't hand a teammate a narrower copy either: scopes are fixed when a key is created and cannot be added later, and the dashboard says configurable scopes are not supported yet.

A shared key also hides who did what. A job's auth_source and the rows of GET /v1/usage intentionally omit API key ids, and the dashboard can tell keys apart but not the people sharing one, so nothing in the record separates one caller's jobs from another's. And if that key leaks, the only fix is revoking it for everyone, as Exposed API key? Revoke it, then check what it did walks through.

How do I share API keys securely?

Share access, not the secret. Each person or service gets a key of their own, and no secret ever travels between people:

• Create one key per person or service on the API Keys page and describe what it's for. The dashboard's own example descriptions are a production feature and a developer's name.
• The full secret is shown once, when the key is created. Whoever creates it stores it straight into a secret manager or CI secret store.
• Never send a key by chat, support ticket, or screenshot. Sume's docs rule out all three, and say keys belong on trusted servers, CI secret stores, or local developer machines.
• If the "people" are your own customers, they shouldn't hold a key at all. Sume has no per-end-user credential: your server keeps one key and works on their behalf, as in How to embed AI video generation in your product.

Should each service get its own API key?

Yes, for three reasons. Every Sume key gets its own per-minute request budget, with reads and writes counted separately, so one service's traffic can't use up another's. In the current dashboard, Last used and Monthly spend on the API Keys page and the Usage page's API key filter then describe one caller each. And a leak or a retired service means revoking one key while the rest keep working.

What separate keys can't split is the workspace itself. Generation concurrency is per workspace and plan-only, so a busy service can fill the workspace's queue until every key's paid submits get 429 queue_full. A team-owned Format also needs a key created in that team workspace; a personal key is refused with 403 workspace_key_required.

What can't separate keys do?

• Give one person read-only access: every key carries the scopes it was created with, and configurable scopes are not supported yet.
• Give one service its own wallet or concurrency: both belong to the workspace.
• Attribute spend over the API: GET /v1/usage rows omit key ids, so per-key figures exist only in the dashboard. There, agent runs and dashboard sessions are recorded without a key.