https://api.fireworks.ai/inference and use the same model ID across each supported API.
Compatible APIs
Choose the endpoint your SDK or client already uses:
For client setup, see OpenAI compatibility, Anthropic compatibility, or the Responses API.
Call the API
Send your Fireworks key and any model ID:firerouter/opus work the same way on all three APIs.
FireRouter examples for every API and SDK
cURL, OpenAI, Anthropic, and Fireworks SDK examples for Chat Completions,
Responses, and Messages, with provider-key headers.
Read the serving model
For a router request, the responsemodel field names the model that served the turn, such as glm-5p3 or claude-opus-5-5, not the router ID you sent. See Verify routing.
Credentials
An Anthropic or OpenAI key in a request header applies only to that request. A key connected through Provider Keys is available at the account level, so clients and gateways do not need to send it with every call.
A route containing both providers needs both credentials. You can combine an account-level key for one provider with a request header for the other.
Fireworks also accepts Anthropic credentials in
x-api-key or Authorization: Bearer. One Authorization header cannot carry both the Fireworks and Anthropic keys. If it carries the Anthropic key, send the Fireworks key in X-Fireworks-Api-Key. Prefer x-anthropic-api-key for new integrations.
In every SDK, api_key is the Fireworks key. Pass provider keys as extra headers, as shown in FireRouter Setup.
Limitations
- Accounts with data residency enabled must use a residency-compatible pinned serverless model. Other model-router requests are rejected.
- Model routers are not available through Microsoft Foundry.
- See What happens without a closed-model credential.
Errors
Model routers and deployment routers
Afirerouter/... id is a model router. Routers load-balance traffic across your own Fireworks deployments.