Providers
List the AI providers that route BatchRouter traffic, inspect a provider's operations and regions, and pin routing to public or edge lanes.
BatchRouter is a routing marketplace: when you submit a batch, the router picks the cheapest eligible provider lane that meets your requirements. Providers are the upstream services behind those lanes — hyperscale APIs like OpenAI and Anthropic, aggregators, and managed edge networks that onboard through the public Provider API. The provider directory is public and read-only, so you can see who can run your work before you create a batch.
This guide covers the two provider endpoints and how providers relate to lanes and the routing_mode
you choose at quote and create time.
Want to sell inference capacity on BatchRouter instead? See Become a provider.
List providers
GET /v1/providers returns the public provider directory — each entry's slug, display_name,
description, is_enabled status, and the supported_operations it can run.
curl https://api.batchrouter.com/v1/providers \
-H "Authorization: Bearer $BATCHROUTER_API_KEY"The response is a providers array. Fields below are illustrative — slugs and names you see are real,
but treat values as a snapshot:
{
"providers": [
{
"slug": "openai",
"display_name": "OpenAI",
"description": "Native OpenAI Batch API for responses and embeddings.",
"is_enabled": true,
"supported_operations": ["responses", "embeddings"]
},
{
"slug": "anthropic",
"display_name": "Anthropic",
"description": "Anthropic Messages batch API.",
"is_enabled": true,
"supported_operations": ["responses"]
}
]
}is_enabled tells you whether a provider is currently routable. A disabled provider stays in the
directory for reference but contributes no lanes to routing. To see which models each provider serves
(and their prices), use the model catalog rather than reading model details out of the directory.
Get one provider
GET /v1/providers/{slug} returns a single provider keyed by its slug (for example openai). The
response wraps the same provider shape under a provider key and includes the provider's
supported_operations and models. A provider profile may also carry richer marketplace metadata —
the provider's processing countries and regions (processing_countries and
supported_regions: published metadata, not an enforced residency guarantee), capacity
signals, and the provider's declared data-retention policy (published, but the router does not
compare the declared retention window against your batch). The full, authoritative field list is in the
API reference; fetch a live provider to see exactly what it
exposes.
curl https://api.batchrouter.com/v1/providers/openai \
-H "Authorization: Bearer $BATCHROUTER_API_KEY"An unknown slug returns 404.
Providers, lanes, and routing
A lane is a concrete way to run a piece of work: a specific provider serving a specific model, with
the provider's region tags. One provider typically offers several lanes. When you quote or create a batch, the
router applies your hard requirements (model, allowed regions, privacy tier, required hosted tools,
deadline), discards lanes that can't satisfy them, then ranks what's left — by price for direct routes —
and selects the cheapest eligible lane (splitting across lanes when one can't finish in time). The
region check compares your allowed_regions with what the provider declares (see
Processing countries and regions), and a provider marked global
always passes it, so it is not a residency guarantee.
routing_mode lets you constrain which providers are even considered:
routing_mode | Effect on provider selection |
|---|---|
cheapest (default) | Any eligible lane, ranked by price. |
sla_aware | Balances price against the provider's reliability and capacity for the 24-hour SLA. |
public_only | Restricts routing to public/hyperscale provider lanes (e.g. OpenAI, Anthropic). |
edge_only | Restricts routing to managed edge provider lanes onboarded to the marketplace. |
hybrid | Allows both public and edge lanes. |
privacy_constrained | Only lanes whose provider satisfies your privacy_tier and data-handling rules. |
Use the directory to inform routing_mode. If GET /v1/providers shows the edge providers you want
are is_enabled and support your operation, edge_only will route to them; if you need the
predictability of the large public APIs, public_only keeps work on those lanes. Set routing_mode
in your quote and reuse it when you create the batch.
Every quote and every batch returns a routing receipt naming the selected lane(s) and why other
eligible lanes were not chosen — so a public_only or edge_only choice is always auditable. See
How routing works for the full ranking and rejection model.
Processing countries and regions
A registered provider declares the country or countries it runs inference in as processing_countries
(lower-case codes such as de or us). BatchRouter derives the provider's supported_regions from
them: the countries themselves, plus eu when every country is an EU member. Every lane of that
provider carries those tags. Built-in providers don't declare countries, so their
processing_countries is empty.
The region check compares your allowed_regions with what the provider declares:
- Work with no region restriction (
allowed_regionsleft out, or containingglobal) can go to any provider. - Region-restricted work goes to a provider with declared countries only when your list covers
every country it runs in, by name or through a group such as
eu. - A provider without declared countries matches when its regions share a value with your list. A
provider marked
globalalways matches, so region is not an enforced residency guarantee.
See Region matching for examples.
When a provider starts taking work
A registered provider sets itself up in the provider portal. When it completes the setup checklist and presses Go live, routing to it starts automatically. There is no manual approval step. A provider must declare at least one processing country before it can go live. BatchRouter operators can switch a provider's routing off and on.