Sume job returns 404 not_found? The key may not own that job

A Sume job id can be real and still return 404 not_found. An API key reads only the jobs that its own member created in the workspace of the key. A job made by a teammate's key, in another workspace, or by a different member in another thread, answers 404 on GET /v1/jobs/:id, /status, /result and /events. Before you suspect a typo, list the jobs your key can see and check whether the id is among them.

Who can read what

The jobs docs state one rule for every read endpoint. The table summarizes it.

Confirm it from the shell

Ask the list endpoint for recent jobs, with the status filter if you want a short list, and look for the id. The list uses the same rule as the single read, so a job missing from the list is a job this key cannot read. A thread_id filter only makes the list smaller; it never widens what a key can read.

#!/usr/bin/env bash
set -euo pipefail
JOB_ID="${1:?usage: check-job.sh job_id}"
BASE=https://api.sume.com/v1
code=$(curl -s -o /dev/null -w '%{http_code}' \
  -H "x-api-key: $SUME_API_KEY" "$BASE/jobs/$JOB_ID/status")
echo "status read: HTTP $code"
if [ "$code" = 404 ]; then
  echo "ids this key can read (latest 100):"
  curl -s -H "x-api-key: $SUME_API_KEY" "$BASE/jobs?limit=100" \
    | jq -r '.data.jobs[] | [.id, .type, .status] | @tsv'
fi

Fixes that work

The same rule explains why a webhook receiver sometimes sees a job that a polling script cannot read: the delivery goes to the URL on the job, while the poll depends on whose key you use. When the two disagree, compare the member behind the key with the member that created the job.

• Read with the key that submitted the job. Keep one key per integration so the owner is obvious.
• If a teammate submitted it, ask them for the result, or have them rerun the read with their own key.
• Store the job id next to the key name in your own log, so a 404 points to the right credential.
• Do not resubmit the paid request to get around a 404. The original job is not lost, and a resubmit with a new key is a second charge.

A quick decision rule

Work through the 404 in this order. First check the id for a copy error, because a truncated id also returns 404. Second, check which key your script loaded: a shell with an old SUME_API_KEY exported is the most common cause. Third, check the workspace of the key with GET /v1/me, which returns the current API key, owner and workspace context. If the key and workspace are right and the list still lacks the job, a different member created it, and only that member's key can read it.

Write the member or key name into your job log at submit time. That one extra column turns this whole investigation into a lookup.