GET /v1/jobs returns 404 for a job another key created: Sume's rules

A Sume API key can read only the jobs that its own member created in the key's workspace. If a reconciler or a support script uses a key from a different member than the one that submitted the job, GET /v1/jobs/{id} returns 404 not_found even though the job exists. A 404 there means "not visible to this key", not "deleted", so do not treat it as a lost job.

Who can read what

The Sume docs give one rule for GET /v1/jobs/:id, /status, /result, /events and the list route. They separate API keys from Studio Agent turns.

Design consequences

• Run submit, poll and reconcile with keys from the same member, or have the reconciler consume webhook payloads instead of reading jobs.
• A webhook delivers the terminal event and result artifacts to your endpoint, so the receiver does not need read access to the job.
• When a turn reads a job another member created, webhook_delivery.url and webhook_delivery.last_error are null. The turn sees the delivery state but not the owner's callback endpoint.
• Only the member that created a job can cancel it.

A reader that explains its 404

The function below separates a hidden job from a transient failure. On a 404 it returns a message that points at key ownership first, which saves an hour of searching for a job that was never lost.

import os
import httpx

def read_job(job_id: str) -> dict:
    key = os.environ.get("SUME_API_KEY", "")
    if not key:
        raise SystemExit("set SUME_API_KEY")
    r = httpx.get(
        f"https://api.sume.com/v1/jobs/{job_id}",
        headers={"Authorization": f"Bearer {key}"},
        timeout=20,
    )
    if r.status_code == 404:
        return {"visible": False, "hint":
                "404 not_found: wrong workspace, or a job created by "
                "another member's key. Check which key submitted it."}
    r.raise_for_status()
    return {"visible": True, "job": r.json()}

print(read_job("job_123"))

Test it once

Submit one job with key A and read it with key B from the same workspace. If key B returns 404, your account follows the documented rule, and your reconciler must use key A or rely on webhooks.

Teams and shared keys

Teams often hit this by accident. One person creates a key for a pipeline, another person creates a different key for a dashboard, and the dashboard cannot see the pipeline's jobs. The fix is not to share one personal key everywhere. Use one key for the whole submit-and-poll path, owned by a service identity, and give people their own keys for their own work.

The Studio Agent rule is the other half. An agent turn can read the jobs in the thread it runs on, including those created by an API-fired Format run, so a teammate who continues the thread can see the results.

A 404 can also mean a wrong id, a wrong workspace, or a job from another workspace. It tells you nothing about whether the work ran or billed. Check the key's member and workspace with GET /v1/me before you open a ticket, and include the request id from the error body if you do.