Skip to content
IQ Routing

Providers

IQ Routing routes each request across whichever providers your org has connected. Every provider is bring-your-own-key (BYOK): you supply your own credential for a provider and the gateway uses it for upstream calls to that provider on your behalf. See Routing for how the routing aliases pick among the providers you've connected, and Models for the current, authoritative list of model ids.

Adding a provider key

Add a provider key from /providers in the dashboard. Per-org provider credentials are encrypted at rest, and each org holds one key per provider. A provider only serves requests for your org once you've added a key for it.

Supported providers

  • AWS Bedrock -- BYOK way to serve the three Claude models listed in the AWS Bedrock section of Models through your own AWS account, once Bedrock routing is turned on (off by default) from /providers.
  • Anthropic -- BYOK inference provider for the Claude model family.
  • Cerebras -- BYOK inference provider.
  • Cohere -- BYOK inference provider.
  • DeepInfra -- BYOK inference provider.
  • DeepSeek -- BYOK inference provider.
  • Fireworks AI -- BYOK inference provider.
  • Google -- BYOK inference provider for the Gemini model family.
  • Groq -- BYOK inference provider.
  • MiniMax -- BYOK inference provider.
  • Mistral -- BYOK inference provider.
  • Moonshot AI (Kimi) -- BYOK inference provider.
  • OpenAI -- BYOK inference provider for the GPT model family.
  • OpenRouter -- BYOK access to the model catalog OpenRouter aggregates.
  • Qwen (Alibaba Cloud) -- BYOK inference provider.
  • Replicate -- BYOK access to the models Replicate hosts.
  • Together AI -- BYOK inference provider.
  • xAI -- BYOK inference provider for the Grok model family.
  • Z.ai (GLM) -- BYOK inference provider.

DeepSeek, Z.ai (GLM), Moonshot AI (Kimi), Qwen (Alibaba Cloud), and MiniMax are China-headquartered companies. As with every provider on this page, BYOK means your requests go directly to that provider's own infrastructure using your org's own key. See Subprocessors for the full list of data handlers.

A key issued for a mainland-China-only console may not authenticate for some of these providers; use the credential type the provider issues for its standard international API access.

Model ids are not listed on this page. GET /v1/models is the authoritative live list; see Models for how to read it.

Custom endpoints

An org on the Team plan or above can add its own OpenAI- or Anthropic-compatible endpoint -- its own URL and its own key -- instead of, or alongside, a named provider. This is how you route to a self-hosted or third-party-hosted model that speaks one of those two wire formats.

Configure a custom endpoint from the dashboard's routing settings, under an Advanced section, or manage it directly through the /admin/custom-endpoints API (listing your org's endpoints is open to any org member; creating, editing, deleting, and testing one need the owner or admin role). Once added, the endpoint becomes a selectable option in your org's routing setup, the same way a named provider is, addressable as the model id custom/<your-endpoint-slug>.

A custom endpoint must meet the following:

  • Wire format. It must speak an OpenAI-compatible or Anthropic-compatible API.
  • Reachability. The URL must be HTTPS and publicly reachable. IQ Routing cannot reach a private network, loopback, or localhost address, so a locally-hosted model -- including hardware on your own network, such as a local GPU box -- needs a public URL or a tunnel in front of it.
  • Price. Price defaults to $0 unless you set one (per-million-token input/output pricing). IQ Routing uses it for cost reporting.
  • Complexity tier. You assign the endpoint to a simple, medium, or complex tier, the same vocabulary used in Routing, so it slots into your org's routing setup at the tier you choose.
  • Fallback role. Set with the auto_use field ("preferred", the default, or "backup"). Preferred: a routing alias (auto, cheap, or frontier) that needs a model at your endpoint's tier tries your endpoint first and falls back to IQ Routing's own choice if it fails. Backup: the endpoint is used only when none of your connected providers covers that tier. Neither setting applies to optimal or custom. A request that names your endpoint directly (custom/<slug>) is an exact pin: on failure it returns an error rather than falling back to a different model.
  • Limit. Up to 20 custom endpoints per org.

Endpoint names and slugs must be unique within your org, and a slug is fixed once set (it's part of the endpoint's model id, custom/<slug>). Your endpoint's API key is encrypted at rest and never returned by the API once set.

Errors

Two refusals mean none of your connected providers can serve the request at all:

  • 402 byok_credential_missing -- None of your connected providers can serve this request -- for example, the request names a model whose provider you haven't connected, or your org holds no key that covers the request at all. Add the missing key from /providers and retry.
  • 409 -- A platform-level control has disabled every provider that could serve this request. This isn't a problem with your account or your API keys; retry shortly, or contact support if it persists.

Other errors you may see:

  • 400 capability_unavailable -- None of your connected models support a feature the request needs. The response names what was missing in a requires list of stable codes, drawn from tools, vision, streaming, forced_tool_choice, context_window, and max_output_tokens -- for example requires: ["tools"].
  • 401 -- Missing or invalid API key. See Auth.
  • 402 plan_required -- The request needs a plan your org doesn't have -- for example, creating a custom endpoint below the Team plan.
  • 403 -- An authenticated member attempted an action that needs the owner or admin role, for example writing a custom endpoint.
  • 400 -- Validation error when saving a custom endpoint: endpoint_url_invalid (not HTTPS, or a malformed URL), endpoint_url_blocked (the URL resolves to a private, loopback, or otherwise non-public address), endpoint_url_unresolvable (the host doesn't resolve), custom_endpoint_slug_immutable (an edit tried to change the slug), or custom_endpoint_model_unsupported (the upstream_model name can't be used with this endpoint, checked on create, on test, and on an edit to upstream_model -- enabling or disabling the endpoint alone never triggers it, and the fix is to serve the model under a different name on your endpoint and use that name instead).
  • 422 validation_error -- A field failed validation, for example a required field left null. The error names the field. (A plain type error, like a string where a number is expected, returns FastAPI's own 422 instead.)
  • 409 -- A custom endpoint conflict: custom_endpoint_duplicate (the name or slug is already used in your org), custom_endpoint_limit (your org already has 20), custom_endpoint_in_use (deleting an endpoint a saved routing table still references -- retry with force=true to detach it from that table first), or custom_endpoint_key_unreadable (from the test endpoint only -- the stored key can't be decrypted; save the key again).
  • 404 -- custom_endpoint_not_found (unknown id) or feature_unavailable (custom endpoints aren't enabled for your org).
  • 429 -- A rate or budget cap fired. See Auth for the per-key limits and FAQ for how to read the response headers.
  • 503 encryption_unavailable or vault_unavailable -- Your endpoint's key couldn't be encrypted right now. Nothing was saved; retry shortly.

Custom-endpoint errors carry a JSON body shaped {"detail": {"code": "...", "message": "...", "field": "..." | null}}, so you can match on code rather than parsing message.

Every response carries an X-Request-Id header; see Quickstart for how to use it to pull up the full trace in the requests browser.

Next

  • Routing -- how aliases pick among the providers you've connected.
  • Models -- the current model roster and ids.
  • Auth -- API key scopes, rate limits, budgets, and revocation.