Get a batch by id

Unix timestamp (seconds).

The API family every record in the batch calls.

Present once results are written; fetch its content for failed records, the records rejected at create included.

When the completion window closes (created_at + 24h).

Batch id (batch_…).

Unix timestamp (seconds) when the batch's first requests started running. Always present and null until then, so an in_progress batch with a null in_progress_at is still queued for GPU capacity.

The model every record runs: the first accepted record's, set when the batch is created.

Present once results are written; fetch its content for successful records.

The scheduling tier this batch runs and is billed at. Batches created before the tier existed read as standard.

Only on the create answer: how many records the create rejected. Read the rejected count here, not from request_counts.failed, which also counts the records that failed running when the create answered after its batch already ran.

Only on the create answer, and only when the create rejected records: the file holding every rejected record (purpose batch_rejections), one BatchRecordRejection per line, in input order. Fetch it with the file content call.

Lifecycle state. validating → in_progress → finalizing → completed | failed | expired; cancelling → cancelled. A batch is in_progress while it waits for GPU capacity too; in_progress_at says when its requests started running.