OpenRouter batch custom_id vs one Sume Idempotency-Key per job

In OpenRouter's Batch API, each item in the requests array is { custom_id, body }, and custom_id must be unique within the batch. For the Sume generation endpoints in these docs, the equivalent is one Idempotency-Key per submitted job, each its own request. Build the key from your item id so a retry of item 7 repeats key 7 and nothing else.

OpenRouter facts are from its quickstart, read 2026-10-01. Sume facts are from Generation admission and Jobs and results.

What does custom_id do on OpenRouter?

It labels one request inside a batch. Submit returns 202 Accepted with status: "validating", and results come back later keyed to your ids. It is a lookup key inside one batch, not a retry guard across submits.

How does a Sume submit map to it?

What does a per-item key look like?

The docs' bulk-loop example uses Idempotency-Key: avatar-batch-001-item-001: batch name plus item number. A submit is accepted the moment Sume has a durable job id, so store that id per item.

const items = ["a", "b", "c"];
for (const [i, item] of items.entries()) {
  const key = "batch-001-item-" + String(i + 1).padStart(3, "0");
  console.log(key, item);
  // POST to your Sume generate endpoint with header "Idempotency-Key": key
}

What breaks if I reuse a key?

Reuse the same key only for the same operation and payload. Per the admission docs, reusing a key for a different operation or payload returns 409 idempotency_conflict; reuse keys only for exact retries, so fix your key derivation rather than retrying as is. For another vendor's id-in-payload pattern, see Replicate's custom id vs Sume's job id.