Batches and safe retries

One intent, one identity

Idempotency-Key is a UUID you save before sending. It identifies a creation intent. The same key and payload retrieve the saved request; the same key with another payload returns 409 IDEMPOTENCY_CONFLICT.

Use another key only for a genuinely new intended creation. Never generate UUIDs inside retry logic: that would turn every attempt into a new intent.

After a timeout:

1. If you received an ID, retrieve that ID.
2. If the response was lost, resend the exact payload with the same key.
3. For quota, queue or rate-limit errors, respect the code and Retry-After.
4. For attention_required, observe the original saved request and contact support if necessary.

Network failure, 5xx, a missing file or slow progress does not prove submission never happened. Infinity Flow retains minimal replay protections after visible history expires.

Submit a batch

curl --fail-with-body 'https://infinityflow.stream/api/v1/batches' \
  -H "Authorization: Bearer $INFINITY_FLOW_API_KEY" \
  -H 'Content-Type: application/json' \
  -H 'Idempotency-Key: f22cd158-5cb4-456b-a0b5-a25c4311a9a2' \
  --data '{"items":[{"prompt":"A forest at sunrise","mediaKind":"video","aspect":"16:9"},{"prompt":"A forest at dusk","mediaKind":"video","aspect":"16:9"}]}'

Replace the illustrative key with a newly saved UUID. Batch admission is atomic: every item must fit the batch, outstanding queue and budget limits before acceptance. The response contains batch.id and child generations. Each child proceeds independently after acceptance.

Retrieve GET /batches/{id}. If a child fails, do not resubmit the entire batch with another key. Recovery must not repeat successful or uncertain children.

Batch size is not concurrency

The number submitted together does not specify how many execute at once. Capacity, leases, priority and operational availability govern execution. Accepted work is eligible immediately; exhausted daily allowance rejects new admission rather than scheduling it for tomorrow.