What is BatchRouter

BatchRouter is a single, OpenAI-Batch-compatible API that routes your batch-AI workloads across many providers. You submit a batch once, BatchRouter quotes the job and dispatches it to the cheapest eligible provider lane that meets your deadline and constraints, then tracks execution, billing, and delivery — and hands you back signed results plus a routing receipt that explains exactly where the work ran and why.

You integrate against one base URL (https://api.batchrouter.com, everything under /v1) and one credit balance. No per-provider accounts, no per-provider SDKs, no lock-in.

The problem it solves

Batch AI is only cheap if you can find the right provider, model, price, capacity, and SLA window at the moment you submit the job. In practice that is hard:

• Provider prices change constantly, and capacity and rate limits are opaque.
• Every native batch provider has a different API and a different SLA window.
• You do not want to compare every provider before every batch — but picking one and sticking with it leaves money and throughput on the table.
• When a job fails or a provider is paused, you are on the hook for retries and reconciliation.

BatchRouter sits between you and batch-capable providers as the control plane. You describe the work and your constraints; BatchRouter owns the routing, the customer pricing, the margin, and the billing — and keeps it all explainable.

When to use it

BatchRouter is the right fit when you have:

• High-volume, latency-tolerant AI work — classification, extraction, summarization, embeddings, enrichment, evaluation — where a job can complete over hours rather than milliseconds.
• A need for cost or capacity flexibility across providers without integrating each one yourself.
• SLA or compliance requirements (a deadline, a region, a privacy posture) that you want routing to respect automatically.
• An existing OpenAI Batch integration you would like to point at a multi-provider backend with minimal code change.

Note

BatchRouter is batch-only by design. It does not optimize for synchronous chat latency and is not a model host — providers own their infrastructure. You buy a quote from BatchRouter, not from a provider directly.

Headline capabilities

SLA-aware lanes

Every batch carries an sla_tier (standard = 24h, flex, or priority) and a routing_mode (cheapest by default, or sla_aware, public_only, edge_only, hybrid, privacy_constrained). Routing applies hard gates first — task support, model compatibility, capacity, rate limits, privacy/region constraints, provider health — then ranks the eligible lanes. By default you get the cheapest lane that can finish in time; large jobs can be split across lanes when that meets capacity or deadline.

Transparent quotes and receipts

Quotes are free. Call POST /v1/quotes/model (or /v1/quotes/workflow) before you commit, and you see the estimated cost up front — credits are only reserved when you create the batch and are settled from actual usage. Every completed batch carries a routing receipt and a billing receipt (GET /v1/batches/{batchId}/billing-receipt) so you can audit exactly what ran, where, and what it cost. Routing is explainable by principle: a quote always shows why a lane was selected.

OpenAI compatibility

A drop-in OpenAI-Batch surface lives under /v1/openai/v1/* (batches and files). Point an existing openai SDK at that base path to create, poll, and download results with no code changes and no webhook required — BatchRouter serializes its native primitives into OpenAI shapes. The native /v1/batches/* and /v1/files/* surface is richer and unchanged; use whichever fits your stack.

Provider marketplace

Providers publish wholesale offerings — models, prices, capacity, regions — into a public catalog you can browse without authentication: GET /v1/catalog/models, GET /v1/catalog/workflow-products, and GET /v1/providers. The marketplace is what gives routing a real choice of lanes, and it grows without any change on your side.

Webhooks and flexible delivery

Results are available by polling (GET /v1/batches/{batchId}/results) or via a signed artifact URL (GET /v1/batches/{batchId}/artifact-url). For push delivery, set a per-batch webhook or an org-wide default (PUT /v1/auth/account/delivery-webhook); payloads are signed with X-BatchRouter-Signature (HMAC-SHA256). You can also configure delivery targets and retention to control where results land and how long they are kept.

How a job flows

1. Quote — POST /v1/quotes/model (free) to see the cost and selected lane.
2. Create — POST /v1/batches with an Idempotency-Key header; you get a 202 and a batch id (bat_…).
3. Poll — GET /v1/batches/{batchId} as it moves through pending → queued → routing → dispatched → processing → completing → completed (terminal states: failed, cancelled, expired).
4. Retrieve — page results from GET /v1/batches/{batchId}/results, or pull a signed artifact via GET /v1/batches/{batchId}/artifact-url.

You authenticate with a Bearer br_live_… key (created in the dashboard or via agent-first registration), and you buy credits in the dashboard — there is no public billing-checkout endpoint.

Next steps

Core concepts Quotes, lanes, SLA tiers, routing modes, privacy tiers, batches, and receipts — the vocabulary in depth.

Quickstart Get a key, quote a job, and submit your first batch end to end.

Interactive API reference Browse and try every endpoint live (Scalar). Raw spec at /openapi.json.