Sume submit: request_id is the job id you poll (curl, jq)

On a successful async submit, the request_id in the response body is the job id. Pass it to GET /v1/jobs/:id and the job record answers with the same value in its id field. There is no separate job_id key to look for in the submit envelope. A request_id inside an error object is a different thing: it identifies the failed request so support can find it, and it is not a job you can poll.

Two ids with the same name

The submit response also carries status_url, result_url and next_poll_after_seconds, so you rarely have to build a URL by hand.

Check it with curl and jq

The script submits an async image job with an Idempotency-Key, reads data.request_id, fetches the job and compares data.id with it. If the submit fails, it prints error.request_id instead. It needs a funded key, so it spends one image job; use any small prompt.

#!/usr/bin/env bash
set -euo pipefail
: "${SUME_API_KEY:?set SUME_API_KEY}"
H="x-api-key: $SUME_API_KEY"
RES=$(curl -s -H "$H" -H "Content-Type: application/json" \
  -H "Idempotency-Key: reqid-demo-$(date +%s)" \
  -d '{"prompt":"A ceramic mug on a desk","mode":"async"}' \
  https://api.sume.com/v1/image-1.0/generate)
ID=$(echo "$RES" | jq -r '.data.request_id // empty')
if [ -z "$ID" ]; then   # a failure: error.request_id is for a support ticket
  echo "failed, quote this to support: $(echo "$RES" | jq -r '.error.request_id // "none"')"
  exit 1
fi
curl -sf -H "$H" "https://api.sume.com/v1/jobs/$ID" |
  jq -e --arg id "$ID" '.data.id == $id' >/dev/null && echo "request_id $ID is the job id"

Store the right one

• Save data.request_id next to your own record the moment the submit returns, before you do anything else.
• Log error.request_id with the HTTP status when a call fails, and keep it out of your job table.
• Use the same id for status, result and cancel calls. The Idempotency-Key is yours and is a different value.
• Resubmitting with the same key and body returns the original job, so the id you stored stays valid.

A common mistake

A retry loop that stores error.request_id as if it were a job id will poll a path that returns 404 not_found, and the loop only ends when its own deadline fires. The cheap guard is to store an id only when the HTTP status is a success and the body has data.request_id. For an error, keep the whole envelope in your logs.

When you reuse an Idempotency-Key and send the same body, the response returns the original job. Its request_id is the id of the first job, so two submits in your logs can point at one job. That is the point of the key, and it is why you should look up your own record by id before you create a second row.