BYOK — bring your own keys

BYOK lets you use your own provider accounts through BharatRouter: one API, one SDK, our routing and failover — your key and your billing upstream. It unlocks providers we don't hold a platform key for (Krutrim Cloud, Sarvam, Mistral, DeepSeek, Together, Fireworks, Cerebras, xAI and 25+ more), and lets you run on your own negotiated rates with providers we do.

Want to route to a model running on a deployment you host, not a provider we support? That's BYOE — bring your own endpoint; see BYOE vs BYOK for which to use.

BYOK requests are free during beta — BharatRouter charges nothing on top; your provider bills you directly.

Two ways to BYOK

1. Per-request: upstream_key

Pass your provider key on a single request. It is used in-flight, never stored, never logged. Combine with provider to pin where it goes:

curl https://api.bharatrouter.com/v1/chat/completions \
  -H "Authorization: Bearer br-..." -H "Content-Type: application/json" \
  -d '{
    "model": "sarvam-30b",
    "provider": "sarvam",
    "upstream_key": "YOUR_SARVAM_KEY",
    "messages": [{"role": "user", "content": "namaste"}]
  }'

2. Saved org keys (recommended)

Save a key once — on the dashboard's BYOK tab or via PUT /me/byok/:provider (org owner) — and every request from your org can use it without the key ever appearing in application code:

PUT /me/byok/krutrim
{ "key": "YOUR_KRUTRIM_CLOUD_KEY", "label": "prod", "always_use": false }

→ { "provider": "krutrim", "mask": "krtm-…a9f2", "always_use": false,
    "verified": true, "models_discovered": 14 }

On save the key is verified live against the provider and encrypted at rest (AES-256-GCM); the plaintext is never returned — only a mask. Re-check a saved key any time with POST /me/byok/:provider/test, remove it with DELETE /me/byok/:provider.

Model discovery

When you save a key, the gateway asks that provider for its model list with your key and makes everything it finds routable as provider/model-id:

GET /me/byok/mistral/models
→ { "provider": "mistral", "models": ["mistral/mistral-large-latest", "mistral/codestral-latest", ...] }

# then simply:
client.chat.completions.create(model="mistral/mistral-large-latest", messages=[...])

Discovery refreshes on key save and on test; a flaky provider listing doesn't wipe previously discovered models.

Key precedence & fallback

1. A per-request upstream_key always wins, and never falls back to a platform key — if your key fails, the request fails.
2. Otherwise, the org's saved key for the selected provider is used.
3. If the saved key was stored with always_use: true, it is exclusive — no platform-key fallback ever.
4. Otherwise, on auth or rate-limit errors from your key the gateway can fall back to the platform key where one exists, so your traffic keeps flowing.

BYOK key failures are attributed to the key, not the provider route — your expired key won't trip the shared circuit breaker.

Which providers accept BYOK?

GET /me/byok returns the live list, including whether each provider has a platform-key fallback. Providers marked fallback below accept your key alongside BharatRouter's platform key; the rest are your-key-only.

🇮🇳 Krutrim Cloudfallback 🇮🇳 Sarvam AIfallback OpenAIfallback OpenRouterfallback Groqfallback Mistral AI DeepSeek Together AI Fireworks AI Cerebras xAI Moonshot AI DeepInfra Novita AI SambaNova Nebius AI Studio Hyperbolic NVIDIA NIM Perplexity AI21 Labs Upstage MiniMax Alibaba Qwen (Intl) Z.ai (Zhipu) Featherless kluster.ai Lambda Chutes Cohere Google Gemini

Full details per provider — residency, fallback, live catalog routes — on the providers page.

BYOK errors

Code	HTTP	Meaning
bad_key	400	The submitted key doesn't look like a valid key for that provider.
unknown_provider	400	No such BYOK provider id — check GET /me/byok.
byok_disabled	503	BYOK is not configured on this deployment.