List Sume jobs for one run_id and count them by status (curl and jq)
GET /v1/jobs filters by run_id, scope and status and returns up to 100 rows. A short curl and jq script gives a count per status for one run.

Call GET /v1/jobs with run_id set to the run you care about, limit=100 and scope=workspace, then group the data array by status with jq. You get a count per status in one request. This is a quick health check for a batch: how many jobs are still queued or processing, and how many failed, without fetching each job.
The filters
The list endpoint takes these query parameters, listed in the OpenAPI spec. An API key sees only the jobs that its own member created, so a count here covers your key's jobs and not the whole workspace. The scope parameter chooses between thread and workspace listings, and run_id narrows either one to a single run, which is how you bound the count to one batch.
| Parameter | Values |
|---|---|
| limit | 1 to 100 |
| scope | thread or workspace |
| run_id | A run id string |
| thread_id | A thread id string |
| type | A job type string |
| status | queued, processing, completed, failed or canceled |
| starting_after | A cursor from the previous page |
The script
It prints one tab-separated line per status. The jq filter was checked against a sample array, but the request needs a live key and a real run id. When the response carries a next_cursor, there are more rows; pass it back as starting_after to get the next page.
#!/usr/bin/env bash
set -euo pipefail
: "${SUME_API_KEY:?set SUME_API_KEY}" "${SUME_RUN_ID:?set SUME_RUN_ID}"
BASE=https://api.sume.com/v1/jobs
# One page of up to 100 jobs that belong to one run, newest first.
curl -sf -H "x-api-key: $SUME_API_KEY" \
"$BASE?run_id=$SUME_RUN_ID&scope=workspace&limit=100" |
jq -r '.data
| group_by(.status)
| map("\(.[0].status)\t\(length)")
| .[]'Reading the counts
- Jobs with status queued or processing are not terminal. Wait for them, or cancel the queued ones. Cancel works only before generation starts, and a job that has started returns 409 job_generation_already_started.
- A failed count above zero means you should read the error object on those jobs. It has category, stage, retryable and next_action fields. Group by error.category next to see whether the failures share a cause.
- One page holds at most 100 jobs. A run with more needs the cursor loop, so a total from one page is a lower bound, not the whole count.
- If the count looks low, check that the same key created the jobs. Other members' jobs are not visible to a key.
Variations
Add status=failed to the query to list only the failures for the run, or type to look at one product. To see the oldest unfinished job, sort the data array by created_at in jq and take the first row with a non-terminal status.
Because the list is one read for up to 100 jobs, it is far cheaper than polling every job. At 30 reads per job per minute for a 2-second poller, a single list call every 10 seconds replaces up to 100 status calls and costs 6 reads per minute.
Sources
Related posts
More in Developers
- Log requested vs stored model ids to find retired ids still in config
Sume runs a retired image id as its successor and stores the successor on the job. Compare the two ids after each submit to find stale config.
- Log the Sume request_id in Python JSON logs, no keys or URLs
A small logging helper for failed /v1/videos calls: keep error.code, request_id and job id, and leave out the API key and signed media URLs.
- Longest AI video clip in one API call: max seconds per Sume model
In one Sume call, Seedance 2.5 and Wan 3.0 reach 30 seconds, Seedance 2.0, Kling v3 Pro and MiniMax reach 15, Gemini Omni Flash 1.1 stops at 10. Full table.
- MAI-Voice-2.1 SSML style="happiness" is not in the voice style list
Microsoft's MAI-Voice-2.1 SSML example uses style="happiness", but the Learn page's own style lists say happy or joyful. Check styles before you ship.
Written by Sume