Disclosure: I work on nRouter. This post was drafted with AI assistance and reviewed by me before publishing.
Most teams I talk to don't run one language. There's a Python service doing the data work, a TypeScript API layer, maybe a Go worker for the high-throughput parts, and a mobile app in Swift or Kotlin. Every one of those needs to call an LLM, and without a gateway each one grows its own provider key, its own rotation schedule, and its own little pile of "which secret goes where" documentation.
That's the problem I keep coming back to when I read our own SDKs page, so here's the practical version of what it sets up.
One key, configured once per service
Every official nRouter SDK reads the same environment variable:
NROUTER_API_KEY=<your virtual key>
...and connects to the same endpoint, https://api.nrouter.ai/v1. Python service, Go worker, Swift app — different clients, one credential lifecycle. Issuing access is one action. Rotating is one action. Revoking a key when someone leaves actually works, because there's nowhere else for access to hide.
The clients, per language
Each SDK ships as a native package in its ecosystem's registry:
- Python — pip install nrouter-sdk
- TypeScript / Node — npm install @nrouter_ai/sdk
- Go — go get the sdks/go/v3 module
- Rust — cargo add nrouter
- Java / Kotlin / Android — Gradle, group ai.nrouter
- Swift — Swift Package from the GitHub repo
- Dart — dart pub add nrouter
- R — the nrouter package
Every row on the page has its own guide, and a few link to runnable demos on GitHub, which is the part I'd copy if I were documenting my own platform. The distance between "installed" and "first successful call" is where integrations quietly die.
Already on the OpenAI client? Don't rewrite anything
The rows I find most honest in the table aren't ours. The standard OpenAI Python client is listed, plus the PHP and Ruby clients, and plain cURL. The deal: point your existing OpenAI or Anthropic client at the nRouter endpoint, keep your call sites exactly as they are. The gateway speaks both wire formats, so the move is a config change, not a refactor.
That ordering matters. Adopt at the configuration layer first, then let the official SDKs earn their way in per service where the typing and guides help.
Why the clients stay thin
One line on the page does the architectural work: every SDK supports automatic cost tracking, server-side guardrails, and centralized fallback routing. Server-side is the operative word. Cost tracking, guardrails and fallback behaviour are gateway properties the clients inherit, not features ten libraries reimplement in ten languages with ten release cadences.
If each client rolled its own retry and accounting logic, "what happens when a provider fails" would have a different answer per service. With thin clients, parity is structural — it can't drift, because there's only one implementation, and it's not in your codebase.
Full table, guides and install commands: https://nrouter.ai/docs/sdks
If you're running a polyglot stack, I'd genuinely like to hear how you handle the key sprawl today — one gateway key, per-service provider keys, a secrets manager pattern? The comments are the interesting part of posts like this.
Top comments (0)