Bring your own key

BYOK (bring your own key) lets you attach your own provider API keys — OpenAI, Anthropic, Google, or any other provider on the platform — in the console. Requests for that provider's models route through your key: the provider bills you directly at your rate, and INFRO charges 5% of what the tokens would have cost at INFRO rates.

Everything else works the same: one endpoint, one sk_infro_... key, and routing, failover, fallbacks, analytics, and spend tracking still apply. Your application code does not change.

When to use it

• Negotiated rates. If your enterprise agreement prices a model more than 5% below INFRO rate, routing through your own key is cheaper.
• Provider credits. Committed-spend or promotional credits with a provider get consumed as usual, since inference runs on your account.
• Data agreements. An existing DPA or zero-retention arrangement with a provider keeps applying, because the provider sees requests from your account, not a pooled one.

How it works

1. Attach a provider key in the console. It is encrypted at rest and becomes the preferred route for that provider's models on your account.
2. Send requests exactly as before — same base URL, same INFRO key in the Authorization header. INFRO forwards that provider's requests through your key.
3. The provider bills the token usage directly to your provider account.
4. INFRO deducts a 5% routing fee from your credit balance, calculated on what the tokens would have cost at INFRO rates.

The response tells you what happened: the top-level provider field reports who served the request, and usage.cost reports what INFRO charged.

{
  "id": "chatcmpl-9f3a...",
  "model": "anthropic/claude-sonnet-5",
  "provider": "anthropic",
  "usage": {
    "prompt_tokens": 1840,
    "completion_tokens": 460,
    "cost": 0.000621
  }
}

Billing

Two charges apply to every BYOK request:

For example, if a request's tokens would have cost $10.00 at INFRO rates, INFRO charges $0.50; the provider invoices you separately at your negotiated rate.

Key precedence

Once a key is attached, it is preferred for every model that provider serves. You can override this per request with routing.providers:

routing.providers.allowstring[]

Restrict the request to the listed providers. Your key is still preferred if its provider is in the list.

routing.providers.denystring[]

Exclude the listed providers. Denying a provider you have attached a key for keeps the request off your key — models with other hosts are served from pooled INFRO capacity at INFRO rates; models only that provider serves fail with 503 no_available_provider.

For example, deepseek/deepseek-v3.2 is served by several providers. If you have a DeepSeek key attached but want a particular request to use pooled pooled INFRO capacity instead:

curl https://api.infro.io/v1/chat/completions \
  -H "Authorization: Bearer $INFRO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek/deepseek-v3.2",
    "messages": [{"role": "user", "content": "Summarize this changelog."}],
    "routing": {"providers": {"deny": ["deepseek"]}}
  }'

See Routing for policies, regions, and the full provider selection order.

Failover

Automatic failover applies to BYOK like everything else: if your key hits a rate limit, errors with a 429/5xx, or times out before the first token, INFRO re-routes the request to the next provider — typically pooled INFRO capacity for the same model, billed at INFRO rates. A saturated personal key slows nothing down.

If every route fails, the request surfaces a normal error — 502 upstream_error when all providers errored, 503 no_available_provider when none was eligible. See Errors for retry guidance.

Model-level fallbacks still apply: if every provider of the primary model fails, INFRO moves to the next model in your fallbacks list. As with all failover, re-routing happens only before the first token — see Streaming for what happens after a stream starts.

Security and revocation

• Encrypted at rest. Provider keys are stored with AES-256-GCM. Key material is never written to logs, analytics, or error messages.
• Scoped use. Your key serves only your own requests for that provider's models — never other accounts' traffic.
• Revocable anytime. Remove a key in the console and traffic for that provider shifts back to pooled INFRO capacity immediately. If you rotate the key on the provider's side, update it in the console — until you do, requests that fail through the stale key fail over to pooled INFRO capacity before the first token.

Request and response content on BYOK traffic follows the same rules as all other traffic, including per-request logging: false and the org-wide zero-logging toggle — see Privacy.

When not to use it

BYOK saves money only when your provider rate is more than 5% below INFRO rate for the same model. If you pay a provider's list price, skip it: INFRO's per-unit prices are at or below list, so your list rate plus the 5% fee comes out strictly worse.

This is most pronounced for open-weight models — deepseek/deepseek-v3.2, meta/llama-4-maverick, qwen/qwen3-coder, and similar — where INFRO pools competing providers and pricing frequently sits below any single host's retail rate. Compare your rate against live pricing on the models page or via GET /v1/models before attaching a key. Credits and data agreements can still justify BYOK at a price loss; pure cost savings usually don't.