Every API integration begins with a key, and most key systems are designed as an afterthought: one account, one secret, displayed whenever you ask, valid until someone remembers to rotate it. nRouter's authentication documentation describes a stricter model, and it is worth studying as a design pattern for anyone building or consuming APIs.

The shown-once rule

An nRouter key — recognisable by its sk-nrouter- prefix — is displayed in full exactly once, at creation. From then on, the dashboard shows only the key's name and its last four characters. That alias is what appears in lists, in conversations, and in request logs.

The security argument is simple: a secret that can be re-displayed will eventually be re-displayed at the wrong moment, in a screenshot or a screen share. A shown-once key removes that failure mode entirely. The documented recovery for a lost key is equally simple: create a new key, move traffic to it, and revoke the old one.

Keys as units of accountability

Authentication on nRouter is not just a gate; each key is a scoped, measurable unit of access:

In practice this means one key per environment or application: the staging key's runaway loop hits the staging key's ceiling, and the audit question "which key made this call, and what did it spend?" is answerable from the logs alone.

Transport and storage

Requests send the key as a Bearer token in the Authorization header (RFC 6750). The key is stored in the NROUTER_API_KEY environment variable; the official Python SDK (nrouter-sdk) and TypeScript SDK (@nrouter_ai/sdk) resolve it from the environment automatically. The documentation's guidance is explicit: keep keys in environment variables or a secrets manager such as AWS Secrets Manager or HashiCorp Vault; never hardcode them, commit them to version control, share one key across unrelated applications, or log full keys.

Revocation and a precise error model

Revocation is immediate: a revoked key is rejected on every subsequent request, while requests already in flight are allowed to complete. Failures are separated cleanly — 401 when the key is invalid, missing, or revoked; 403 when a valid key lacks permission; 429 when the key exceeds its own rate limit. The error payload uses type authentication_error with code invalid_api_key for authentication failures.

The takeaway

Shown once, stored outside the code, scoped per job, budgeted per key, logged by alias, and revocable in an instant: six properties, all documented on one page — the authentication guide at https://nrouter.ai/docs/getting-started/authentication. Whatever platform you build on, that list is a sound grading rubric for its key system, and for your own.