A teammate's music job id returns 404 with your API key: why
An API key reads only jobs its own member created in the workspace; anything else is 404 not_found. How to share a track or narration job with a teammate.
If you read a colleague's music or narration job with your own API key and get 404 not_found, nothing is broken: an API key reads only the jobs its own member created in the key's workspace. The jobs and results docs, read 2026-10-03, state that everything else is a 404, including jobs in other workspaces and other members' jobs, so the job exists but your key may not see it. The fix is to pass the finished artifact, not the job id.
Who can read which job?
A thread_id filter on a job list narrows results and never widens what a key may read.
| Caller | Reads | Otherwise |
|---|---|---|
| API key | Jobs its own member created in the key's workspace | 404 not_found |
| Studio Agent turn | Every job in the thread it runs on, whoever created it | 404 not_found outside the thread |
| Any caller, other workspace | Nothing | 404 not_found |
How do I hand a track to a teammate?
Send the media.sume.com audio URL from the finished result rather than the job id. Audio tools such as audio detach and Timeline audio take workspace-hosted media URLs, so your teammate can use the file as an input in the same workspace without reading your job. If they need to cancel the job, note that only the creating member can cancel it.
What should you watch for?
- A batch
jobs_waitwith one foreign or unknown id fails the whole call, so keep batches to ids your own key created. - Usage is recorded against the member who created the job, so a shared key concentrates spend on one person.
- I did not test whether a teammate's artifact URL stays readable for other members; confirm before building a handoff on it.
Sources
Related posts
More in Developers
- Temporal Standalone Activity heartbeats: resume polling a Sume job
Heartbeats signal liveness and checkpoint progress for retries. Put the Sume job_id in the heartbeat so a retry resumes polling instead of paying again.
- Temporal Activity ID Reuse Policy vs a Sume Idempotency-Key
Temporal's Activity ID Reuse Policy covers closed Standalone Activities; Sume's Idempotency-Key covers a retried submit. Why one does not replace the other.
- Temporal Standalone Activity Start Delay: a scheduled Sume submit
Start Delay holds only the first Activity Task; retries follow the Retry Policy. A delayed Sume submit needs one stable Idempotency-Key for every attempt.
- Test two caption looks on one Reel with source_caption_id
Restyling captions with source_caption_id reuses the first caption job's video and word timings, so no second transcription runs. Billing stays one render each.
Written by Sume