API audit log: what you can trace on Sume's media API

Sume's docs do not describe an audit-log endpoint. What the API does give you is three records you can line up: job records with timestamps, a usage ledger with job and request ids, and a request id on every response. Those rows leave out API key ids and prefixes, so they cannot tell you which key made a call.

This comes from the Jobs dashboard and Usage dashboard pages, the Errors and rate limits page, and the Sume API reference, read 2026-09-29. Where the docs say nothing, this post says so.

Which records can I line up?

Three reads cover most audit questions: what ran, what it cost, and which request to quote to support. The job, usage and key reads are scoped to the workspace of the key you call with.

Can I tell which API key made a call?

Not from job or usage rows. Both carry an auth_source field that says only api_key, and the reference describes it as non-identifying: API key ids and prefixes are intentionally omitted. GET /v1/me does return a key's id, name, prefix and scopes, but only for the key you send.

So attribution is yours to record. The job row returns the Idempotency-Key it was created with, and the reference calls that the join column: map your own key to the job id instead of reading identity off array position.

How do I pull the trail for one job?

List jobs, filter on status if you only want failures, then read the ledger rows for a job id. The usage call takes job_id, run_id or thread_id to narrow the ledger to one scope.

curl -sS "https://api.sume.com/v1/jobs?status=failed&limit=100" \
  -H "Authorization: Bearer $SUME_API_KEY"

curl -sS "https://api.sume.com/v1/usage?job_id=job_123" \
  -H "Authorization: Bearer $SUME_API_KEY"

What does a usage row say happened to the money?

A usage row's status is reserved, captured or refunded. Reserved means estimated usage was held before the provider ran; captured means billable usage was taken after success; refunded means the hold was released after a failure or cancellation before capture. The dashboard page says to use job ids and request ids to correlate usage rows with generation workflows.

What can an audit not get from the API?

Read this as the gaps, not as a promise about the future.

• No documented audit-log endpoint or export. The usage list is capped at 100 newest rows per call.
• No key attribution on job or usage rows, as above.
• No retention period for job or usage records in the pages checked. If your policy needs one, ask before you rely on it; see what Sume keeps.
• No record of who in your own product triggered a call. Your backend holds the API key, so log the end user there.

What does the dashboard add?

The Jobs dashboard shows recent Developer API jobs with status, mode, public result or error data, and timeline information where available. The Usage dashboard gives a human summary of metered activity. Use them to eyeball a run; use the API reads to keep a copy.

Quote the request id when you report an issue, and leave API keys, signed URLs and raw media URLs out of the report.