Dashboard
You're not signed in. Sign in to manage keys.
🏢 Your organisation is on BharatRouter.not now
Recent activityview all →
Invoices & receipts— download GST tax invoices for your credit purchases
| Amount | Credits | Date | Invoice |
|---|---|---|---|
| Loading… | |||
Auto-rechargecoming soon— auto top-up when your balance runs low (Razorpay e-mandate). Until then, use the low-balance email alert above.
Your new API key — copy it now, it won't be shown again:
Ready-to-run curl (your key is already in it)
Response
Full docs: quickstart · Python/Node samples included.
API keys
| Key | Name | Tier | Today | 30 days | Last used | |
|---|---|---|---|---|---|---|
| Loading… | ||||||
Where did you first hear about BharatRouter?skip
An agent identity lets a bot authenticate to inference with its own short-lived, auto-expiring token instead of a shared API key — so there's no static secret to leak, every call is attributed to this agent, and you can kill it instantly. BharatRouter provisions the identity for you; you don't run any identity server.
⚠ Identity service is degraded.
BharatRouter is still running. Agents holding a valid token keep working (verified offline); issuing new identity tokens is paused until Ekam recovers — this clears automatically.
Embedded provisioning isn't wired up on this deployment.
New agent
Your agents
| Name | Identity | Status | Budget (₹/mo) | |
|---|---|---|---|---|
| Loading… | ||||
If the identity service has an outage
Choose how your agents behave when Ekam is unreachable. Neither option ever admits an unauthenticated agent — both require a valid signed token. The choice is only whether to insist on a live revocation check during the outage.
Saved ✓Already run your own Ekam? Bring it as a trusted issuer instead of having BharatRouter provision identities → Bring your own Ekam (advanced)
Identity token for
Authorization: Bearer … to Usage insights— token mix and where consumption concentrates (follows the range/model filters above)tokens ·requests
Daily tokens by type— input · output · cached (prompt-cache reads)
Top providers by tokens
Top models by tokens
Top users by tokens
Top models — realized cost across all providers that served them
| Model | Requests | Tokens | Spend | ₹/req avg | ₹/Mtok realized |
|---|---|---|---|---|---|
| Loading… | |||||
Top keys
| Key | Requests | Tokens | Spend |
|---|---|---|---|
| Loading… | |||
Requests newest first — follows the filters above
| When | Model | Provider | Key | Status | Latency | Tokens | Cost |
|---|---|---|---|---|---|---|---|
| Loading… | |||||||
Fallback chains— org-wide routing: requests for a model walk YOUR chain in order, across providers and even across models
| Model | Chain | Updated | |
|---|---|---|---|
| Loading… | |||
Same JSON for agents: PUT /me/routing/<model> or theset_fallback_chain MCP tool. Per-request fallbacks overrides a saved chain. Test chains live in the failover playground.
Your custom endpoints (BYOE)— register your OWN OpenAI-compatible deployments as fallback steps for a model (priced ₹0 — your infra). Admitted to routing only after a compliance test. Multiple per model allowed.
| Name | Model | Endpoint | Status | |
|---|---|---|---|---|
| Loading… | ||||
Agents: POST /me/endpoints or the register_endpoint MCP tool. Keys are encrypted at rest and never shown again. Once registered & compliant, pick it as a step's provider below.
New chain
Requests forare served:
Failover: try each step in turn until one succeeds. Weighted: split live traffic across steps by their weight (health-adjusted) — set a weight per step below.
Use-case evals— score candidate models on a golden set; the winner becomes a collection's routing (eval-gated cross-model).
| Eval | Cases | Latest run | |
|---|---|---|---|
| Loading… | |||
Cases (JSON array of {prompt, expect?, grader?} — grader: contains│equals│regex│nonempty):
Candidates (JSON array of model ids or {model, provider?}):
Agents: POST /me/evals, POST /me/evals/:id/run, GET /me/evals/runs/:id.
Workspaces— operational environments inside your org (e.g. Production, Staging, per-team). Each scopes its own API keys and usage; your org keeps the single wallet, members and billing.
| Workspace | API keys | Budget (₹/mo) | Created | |
|---|---|---|---|---|
| Loading… | ||||
How it splits: a workspace owns the operational side — its API keys and (soon) BYOK keys, ₹/mo budget caps and guardrails. Your org owns everything legal & financial — one wallet, members & roles, GST/billing. New keys land in whichever workspace you pick; keys with no workspace sit in the org default. Same JSON for agents: GET/POST /me/workspaces.
Provider keys (BYOK)
Bring your own provider key: requests to that provider ride your account instead of BharatRouter's. Keys are encrypted at rest (AES-256-GCM), used only in-flight, and never shown again after saving. Saving a key also discovers that provider's models — call anything it serves as provider/model, even beyond our catalog.BYOK requests are free during beta.
Plan & usage
Loading…
Same JSON for agents: GET /me/entitlement.
Org instructions— a system prelude the gateway injects ahead of EVERY chat request from your org (compliance, terminology, data-handling). Users can't strip it.
Provider egress allowlist— govern which providers/models your org may route to (a residency / data-governance lever).
Mode:
| Provider | Model | Effect | |
|---|---|---|---|
| Loading… | |||
Agents: /me/org/governance, /me/org/egress, /me/org/egress/rules.
Data retention— BharatRouter is zero-retention by default. Some models require a non-zero upstream retention window and stay off until you opt in.
Console: PUT /me/org/data-retention with enabled: true. Agents (management key): MCP get_data_retention / set_data_retention. Takes effect within ~60s.
Monthly ₹ caps at any level — spend rolls up, and the tightest cap that touches a request wins: when any level hits its cap, requests stop until you raise it or the new month begins (IST). Caps work on BYOK too.
Spend caps— org → teams → workspaces → members → keys
Loading…
Provider & model caps— cap spend on a specific provider or model inside a workspace, e.g. ₹2,000/mo on one provider in Production.
Loading…
Set a provider, a model, or both. Leave one blank to cap a whole provider or one model across providers.
Members
This is your personal org — single-user by design. Create a team to share credits, keys and provider accounts: teammates are invited by email and join when they accept from their own dashboard (no invite links to forward).
| Member | Role | Budget ₹/mo | |
|---|---|---|---|
| Loading… | |||
They get an email and an in-dashboard invitation tied to this address — membership starts only when they accept it (signed in with the OAuth-verified email, no forwardable links).
Per-member ₹/mo caps set here also appear on theBudgets tab; colleagues on a verified domain auto-join without an invite.
Domains — verify a domain to auto-join your colleagues
Add your company's email domain, then create the DNS TXT record we show to prove you control it. Once verified, colleagues signing in with that domain's email auto-join this org as members (up to 20 domains). Public email domains (gmail, outlook…) can't be claimed.
Enterprise SSO (SAML) & SCIM— sign-in via your IdP + automatic user provisioning. Needs a verified domain above; Enterprise feature.
Grant credit— goodwill / promo credit, fully audited (replaces hand-rolled SQL)
Search a user by name or email (or paste the exact address), then grant credit with a reason. Grants apply immediately and are recorded in the audit log (who, when, why).
Enterprise requests— org owners who asked for the Enterprise tier; approve flips orgs.plan and notifies them
Audit log— every credit action, newest first
| When | Action | Org | By | Amount | Reason |
|---|---|---|---|---|---|
| Loading… | |||||
Profile
Signed in as via — email and photo come from your sign-in provider; email can't be changed here.
Organisation
Shown on receipts and team invites. Monthly spend caps (org / workspace / member / key) live in Budgets.
Billing address
Used on payment receipts; the state decides GST treatment once invoicing starts. PIN code fills city and state for you.
Platform provider keys founder
Our own upstream keys — stored exactly like customer BYOK (AES-256-GCM, masked, decrypted only in-flight). test keys only feed our health + benchmark checks (latency / throughput / uptime per provider & model, published declared-vs-tested) and never carry routed traffic; serve is reserved for keys we route on (Krutrim). Add or rotate with no redeploy.