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.

4 min readSume
All posts

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.

GET /v1/jobs query parameters from the OpenAPI spec, read 2026-10-08
ParameterValues
limit1 to 100
scopethread or workspace
run_idA run id string
thread_idA thread id string
typeA job type string
statusqueued, processing, completed, failed or canceled
starting_afterA 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

All Developers posts

Written by Sume