GET /v1/jobs/{id} returns 404 for a job your teammate created

A 404 not_found on GET /v1/jobs/{id} for a job you know exists usually means the job belongs to a different member than the one who owns your key. A Sume API key reads the jobs its own member created in the key's workspace. Jobs created by a teammate, even in the same workspace, read as 404, exactly like a job that never existed.

The rules are in Jobs and results, read 2026-10-02, with the status table in Errors and rate limits.

Who can read which job?

A job belongs to its workspace and to the member whose key or Agent turn created it. Its usage is recorded against that member, and only that member can cancel it. The reads (GET /v1/jobs/:id, /status, /result, /events and the list GET /v1/jobs) follow one rule.

Why 404 and not 403?

The docs list the cases that collapse into 404 not_found: jobs in other workspaces, other members' jobs in other threads, and, for an API key, any job its member did not create. The docs do not give a reason, but one effect is that a key cannot tell a missing job from someone else's job. Elsewhere in the API, a 403 means the key is valid but lacks a scope. If you see 403, check key scope; if you see 404, check who created the job and which workspace the key belongs to.

How do I find the job then?

Start from the creator. If a teammate submitted the work, the job id and its results are readable with a key from that member. If you need shared visibility, route the work through a surface that reads at the thread level: a Studio Agent turn reads every job in the thread it runs on, including jobs an API-fired Format run made in that thread.

A thread_id filter on the list narrows results and never widens what a key can read, so adding it will not reveal other members' jobs.

# Works only if this key's member created job_123
curl -i https://api.sume.com/v1/jobs/job_123/status \
  -H "Authorization: Bearer $SUME_API_KEY"

# List shows only jobs this key's member created
curl -sS "https://api.sume.com/v1/jobs" \
  -H "Authorization: Bearer $SUME_API_KEY" | jq '.data | length'

What about webhook details on shared jobs?

When a turn reads a job another member created, webhook_delivery.url and webhook_delivery.last_error come back null. The turn sees the delivery state but not the owner's callback endpoint. Cancel is stricter still: only the member that created the job can cancel it.

Practical rule for services: submit and poll with the same key, and persist the job id next to the key that created it. If a worker pool uses several keys, a poller using the wrong key sees a wall of 404 responses that look like lost jobs but are not.