The Message Batches API, in full

What this table actually governs

These are the mechanical limits and economics of the Message Batches API itself — price, size limits, and how long results stay available once a batch completes. None of it tells you whether batching is the right call for a specific workload; that's a separate question covered by the batch vs realtime calculator, which takes your actual volume and deadline rather than the raw platform limits alone.

The platform gap that's easy to miss

The unavailable-on figure in this table is not a rollout-in-progress detail — it's the current, standing state of where this endpoint exists at all. Code that works cleanly against the first-party API can fail outright the moment it's pointed at one of the platforms where this endpoint simply isn't offered, regardless of which model is being targeted through it. See the Batch API isn't available on your platform for exactly what that failure looks like.

Retention is a real deadline, not a formality

The retention figure above is the hard limit on how long a completed batch's output stays fetchable at all — past it, an unretrieved result is simply gone, not archived somewhere else. See using the Message Batches API for what a pipeline that respects this deadline actually looks like end to end.

Size limits matter for submission strategy, not just eligibility

The maximum requests per batch and the maximum total batch size both shape how you should actually submit a large workload — a workload that exceeds either limit needs to be split across multiple batches rather than submitted as one, and planning that split in advance is simpler than discovering the limit mid-submission on a workload that was assumed to fit in one batch.

Related

See using the Message Batches API for the implementation mechanics this table underpins, and when batch processing is worth the wait for the decision this table's raw numbers feed into.