GET /v1/jobs thread_id filter: why a teammate's job still 404s

On the Sume jobs list, a thread_id filter only narrows the result. It never widens what an API key can read: a key still sees only the jobs its own member created in the key's workspace, so passing a teammate's thread id does not reveal their jobs. Jobs outside that scope answer 404 not_found.

The rule is in Jobs and results. This page covers the two places people trip over it: filtering a list by thread, and cancelling a job someone else created.

What does the thread_id filter actually do?

It reduces the list returned by GET /v1/jobs to jobs tied to that thread. That is all. The authorization check runs first and the filter is applied inside whatever the credential is allowed to see.

So with an API key, a filter for a thread that mixes your jobs and a teammate's returns only yours. With a Studio Agent turn the visible set is larger, because a turn reads every job in the thread it runs on, whoever created it, but that is a property of the turn and not of the filter.

Why does a teammate's job return 404 and not 403?

The docs list the 404 cases together: jobs in other workspaces, other members' jobs in other threads, and for an API key any job its member did not create. Returning 404 for all of them means a key cannot probe whether a job id exists elsewhere.

That matches how Formats handle run reads, where a run you cannot see reads the same as one that does not exist. Treat a 404 not_found on a job id you were handed as an access question first and a typo second.

Who can cancel a job?

The docs say usage is recorded against the creating member and only that member can cancel the job. Cancellation also has a timing limit: it succeeds only before generation work starts. After that the API returns 409 job_generation_already_started with details.cancelable: false and the job runs to completion.

Cancelling a job that is already canceled is idempotent and returns the same canceled job, so a retry after a network error is safe.

The docs do not say what a non-creator's cancel call returns. Since a key cannot read another member's job at all, assume it is indistinguishable from an unknown job and do not build logic on a specific status.

How do I list my own jobs for one thread?

Call the list with your key and the filter. The response contains only jobs your key's member created:

curl -sS "https://api.sume.com/v1/jobs?thread_id=$THREAD_ID" \
  -H "Authorization: Bearer $SUME_API_KEY"

What should a team do instead of sharing one key?

Keep each automation on a key owned by the member or service that should own the spend, and store job ids with the key that created them. If a teammate needs to see results, the supported path is the thread: a Studio Agent turn on that thread reads every job there. The Generation admission page notes that queue counts are per workspace, so a shared workspace queue still sees everyone's jobs even though reads are per member.

Record the job id the moment you submit, because there is no way for a different key to rediscover it by listing.