One shared key after Sora? Who can read which Sume job

If a Sora integration shared one project key between a web app and a worker, every process could look up any video id. Sume scopes job reads by member. Per the jobs guide, a job belongs to its workspace and to the member whose key created it, and an API key reads only jobs its own member created. Anything else returns 404 not_found. If your web app submits with one key and your worker polls with another, the worker sees nothing.

The read rule in one table

The guide names the rule for the job reads: GET /v1/jobs/:id, /status, /result, /events and GET /v1/jobs.

What breaks in a ported pipeline

Three patterns fail. A worker with its own key polls a web-created job and gets 404, which looks like a deleted job. A cancel from a second key fails because only the creating member can cancel. And a per-developer key used in a cron job ties the pipeline's read access to that one member, because jobs belong to the member who created them.

A layout that works

Pick one submitting identity per pipeline and use that key everywhere the pipeline reads or cancels. Keep it in a secret store as SUME_API_KEY, and give each environment its own key so staging jobs never mix with production. Store the returned job id in your database, as the Sora-era video id was, and carry it through every hop.

If a second system only needs the result, hand it the Sume media URL from the job result instead of the job id. The docs tell you to use the Sume media URLs from the result rather than raw provider URLs, so hand over those URLs and confirm in staging that the second system can fetch them without a key.

• One key per pipeline and environment.
• Submit, poll, cancel and redeliver with the same key.
• Use webhooks to push results to services that should not hold the key.

Test it before cutover

Submit one job with key A and read it with key B. Expect a 404 and fix the layout in staging, not on launch day. The webhook route covers the other direction: Sume sends the terminal event to your URL, so a receiving service needs the signing secret, not the API key. See the API reference for the account and key routes.