Exposed API key? Revoke it, then check what it did

If an API key is exposed, treat it as stolen: anyone who saw it can use it until you revoke it, and deleting the commit, the chat message, or the screenshot doesn't change that. Revoke it, move your integration to a new key, then check what the key did while it was out.

For a Sume key, that means creating a replacement, deploying it, confirming it with GET /v1/me, and revoking the exposed key in the dashboard, then reviewing the key's last use, its spend, and your jobs and runs. Sume facts come from Authentication, Verifying webhooks, and Jobs and results, read on 2026-09-27, plus current API and dashboard code where noted. Routine rotation is covered in How Sume API keys work.

How do I revoke an exposed API key without breaking my app?

Sume's docs give that order, and say to rotate any key that appears in logs or chat history:

• Create the new key on the API Keys page. The dashboard reveals the full secret only when a key is created, so store it in your secret manager right away.
• Replace the old value wherever it lived, in your secret store rather than in code.
• Call GET /v1/me with the new key. It verifies the key and the workspace it resolves to, and returns key metadata such as id, name, prefix, and scopes, never the secret.
• Revoke the exposed key. From then on it gets 401, the status Sume uses for a missing, malformed, or revoked key. Current API code caches each key lookup for up to 15 seconds by default, so the old key can keep working that long after you revoke it.
• If someone is spending on the key right now, revoke first and accept a short outage in your own app.

curl https://api.sume.com/v1/me \
  -H "Authorization: Bearer $SUME_API_KEY"

What could someone do with my exposed key?

Spend your money. Sume keys are workspace-scoped, and the docs put it plainly: a key spends your credits, and anyone holding it can run any Format you own, up to your caps.

It can also reach your webhook signing secret: any key carrying account:read can read it from GET /v1/webhooks/signing-secret, and one carrying account:write can rotate it. Whoever holds the secret can sign a fake delivery your receiver would accept, so unless you know the exposed key lacked account:read, rotate the secret too (Webhooks, then Rotate secret). For 24 hours after a rotation Sume signs every delivery with both the new and the old secret; its docs say rotating twice inside that window retires the secret two rotations back (the leaked one) immediately, which is what makes a leak stop. Then deploy the newest secret. First make sure your receiver accepts any sume-v1= entry in the signature header: one that compares the whole header fails every delivery during the window.

How do I see what the exposed key did?

Start in the dashboard, which can tie work to a key; the API can't. Over the API, job and usage rows leave out key ids and prefixes, so there you judge by time: anything between the leak and the revocation that your own systems didn't start is suspect.

In a team workspace, do this from the account that created the exposed key (the API Keys page's Created by column). Current code shows each member only their own jobs, on the Jobs page and over the API, so jobs submitted with another member's key don't appear.

Does revoking a key stop jobs it already started?

Revoking refuses the key's next requests. Sume's docs don't describe it canceling anything already accepted, so stop unwanted work yourself, with a new key from the same account as the exposed one:

• A generation job cancels with POST /v1/jobs/{id}/cancel only before generation starts. After that the API answers 409 job_generation_already_started and the job runs to completion, so list status=queued jobs first.
• A Format run cancels with POST /v1/format-runs/{run_id}/cancel. Generation it completed before the cancel is still billed.
• Routes and responses for each cancel are in How to cancel an AI video generation job or run.

How do I keep API keys from leaking again?

Follow the custody rules in How Sume API keys work: keys stay on servers and in secret stores, never in frontend JavaScript, mobile apps, support tickets, or screenshots. Two habits also limit the next leak:

• Don't paste keys into chat; Sume's MCP quickstart says the same.
• Give each service its own key, so one leak means one revocation and the dashboard's per-key records point at one caller. Can multiple people use the same API key? covers what separate keys do and don't split.