Skip to main content
The Batch API lets you submit many inference requests together and retrieve the results asynchronously. It’s useful for work that doesn’t need an immediate response, and it uses a 24-hour completion window so you can process requests without managing each call yourself. The Batch API supports several OpenRouter API shapes, including chat completions, Responses, and Anthropic Messages. You submit requests as an inline JSON requests array. You don’t upload a JSONL file; OpenRouter handles JSONL persistence internally.
Batch results are available asynchronously. A successful submission returns 202 Accepted with status: "validating", which means the request was persisted and queued for validation, not that every request has completed.

Submit a batch

Submit a batch with:
Endpoint
The request body has three required top-level fields:
Serialize endpoint and model before requests in the JSON body. The API stream-parses the request so it can accept very large requests arrays without buffering, and it returns a 400 if requests appears first. Every example on this page already uses this order.
The batch-level model applies to every request. A request body can omit model to inherit the batch-level value. If a request body sets its own model, it must match the batch-level model or the submission is rejected.
The response is a batch object with an ID you can use to check progress:
202 Accepted
The only supported completion window is 24h.

Poll for results

Use the batch ID to retrieve the current status:
Endpoint
For example:
Shell
The status normally progresses through:
Status progression
Other possible statuses are failed, expired, cancelling, and cancelled. The terminal statuses are completed, failed, expired, and cancelled. Poll until the batch reaches a terminal status. request_counts contains the total number of requests and the number that completed or failed:
request_counts
When a batch is in progress, or has failed, expired, or been cancelled, results is null. When a batch completes, results is returned inline as an array in the same response. There is no separate results-download endpoint. Each result maps back to an input using custom_id. Exactly one of response or error is populated for each result:
Result item
A completed batch response looks like this:
Completed batch

Reporting issues

Each completed result’s response.body.id is that request’s OpenRouter generation ID (for example gen-batch-...). To flag a bad generation, copy that ID and submit it through Report Feedback using the By generation ID flow.
Generation-level feedback is available for the /v1/chat/completions, /v1/responses, and /v1/messages skins. You can also share feedback or report issues in our Discord.

Use different API shapes

Set the top-level endpoint to choose the request shape used by every body in the batch. Supported shapes:
  • Chat completions: /v1/chat/completions
  • Responses: /v1/responses
  • Anthropic Messages: /v1/messages
For example, an Anthropic Messages batch uses /v1/messages and puts the Messages-shaped request in each item’s body:
Anthropic Messages batch
All requests in one batch use the same top-level endpoint. To mix API shapes, submit separate batches.

Embeddings

Embeddings are rolling out on providers that support them. Set the top-level endpoint to /v1/embeddings and put the embeddings request in each item’s body. Each body takes an input (a string, an array of strings, a token array, or an array of token arrays). Multimodal inputs, input_type, and provider preferences are not supported on the Batch API. Use the sync API for those. An input can be a single string or an array of strings. When it is an array, that request embeds every string in one call:
Embeddings batch
Poll for results the same way as any other batch (GET https://openrouter.ai/api/beta/batches/:id). These items are the entries of the completed batch object’s results array (shown in full above); each carries the standard embeddings response in its body, and there is one result item per custom_id. A request whose input is an array of strings returns one embedding object per string in data (ordered by index); a single-string request returns exactly one:
Embeddings results
Batch inputs and results are stored as JSONL artifacts in Google Cloud Storage and automatically deleted 30 days after creation, matching the upstream batch retention window. Download any results you need before the 30-day retention window elapses.