Revoked a Sume API key: does its past spend disappear from Usage?
No. Revoking a key does not cancel the attribution of past spend. Rows tied to the key id keep their origin; mismatched rows are skipped, not guessed.
Revoking a Sume API key does not rewrite history. Sume's attribution doc says a revocation does not cancel the attribution of historical spend, so charges that were stamped with that key id stay tied to it. The key stops working for new calls; the money it already moved remains explained in your Usage records.
What the doc says
In docs/operations/api-key-spend-attribution.md, the backfill verified that all candidate key ids agree, resolve in developer_api_keys, and match the usage workspace and key owner. The text then says a revocation does not cancel the attribution of historical spend. A row with a missing origin is skipped; a row whose ids disagree, whose key record is missing or whose ownership does not match is unsafe.
Why Sume will not guess
The backfill refused thread-only joins and key-prefix guesses, because one thread can contain runs from different keys. Exact job ids or exact automation-run ids can recover the real key id. Anything else stays in the residual. That choice favors a true "unknown" over a false "this key did it".
After a leak
If a key was exposed, revoke it first, then read what it did. See exposed API key: revoke, then check. The by-key view and /v1/usage let you find the runs, jobs and threads that carry the key's stamp, and you can read each one's exact cost from the usage summary.
What not to conclude
Do not treat an empty by-key row as proof nothing happened. Historical MCP usage may sit in the residual because no exact origin id was stored at the time. When in doubt, open the specific thread or job through /v1/usage with thread_id, run_id or job_id.
Audit trail checklist
After revoking, export the run, thread and job ids that your logs tie to the key, and read each cost from the usage summary. Keep that record with the incident notes. Then create a replacement key with a new name and update callers.
Because attribution survives revocation, the old key id remains useful as evidence long after it stopped working.
Related posts
More in Developers
- Rolling a webhook secret: Stripe's 24-hour overlap vs Sume's header
Stripe can keep an old signing secret live for up to 24 hours. Sume sends one sume-v1 entry per live secret; verify any match. Python verifier included.
- Rotate the Sume webhook secret without dropping deliveries
Sume signs with both secrets for 24 hours after a rotation, comma-separated in x-sume-webhook-signature. Upgrade the verifier first, then rotate. Steps inside.
- Route a Kling video job in Python: scene, motion clip or 30 seconds
A small Python router for Sume: performance copies go to Kling motion control, 4-15 s scenes to kling-3, and longer jobs to a catalog id that lists 30 s.
- Route low-confidence transcripts to review: STT language_probability
Sume STT returns language_code and language_probability. Flag results under a threshold you set and send them to a person. Python, about 10 cents per file.
Written by Sume