Authentication

Every Nora /v2 endpoint authenticates with a single header: X-API-Key. No bearer tokens, no OAuth, no cookies, no separate org or instance headers. The key is the whole credential — the backend derives everything else from it.

The one header

X-API-Key: sk_live_...

That's it. You'll never send an org-scoping header, an instance- scoping header, or a bearer token alongside it. /v2 has no legacy cp-* scoping headers — if a snippet you're porting from an older /cp integration shows any of them, drop them — /v2 ignores them and scopes only by the key.

How a key binds

Every key encodes a tuple: (organization, instance). When Nora receives a request, it looks up the key and resolves that tuple on the server. There's no way to "call a different org with the same key" — every query the backend runs is scoped by whatever org and instance the key maps to.

Concretely: if you need to call sandbox and production, that's two keys. If you need to call two different organizations, that's two keys. Keys are not portable.

Sandbox vs production

The prefix is informational — the authoritative binding is in the server-side lookup. Pointing a sandbox key at api.nora.finance, or a production key at staging.api.nora.finance, always returns a 401. There is no cross-environment call.

Rotation

There is no in-place rotate endpoint. The rotation pattern is:

1. Create a new key in the dashboard (give it a dated name, e.g. backend-2026-04).
2. Swap the secret into your config (env var, secret manager, etc.).
3. Deploy and verify traffic flows cleanly on the new key.
4. Revoke the old key.

Revoked keys return 401. If your tooling needs to distinguish "never valid" from "revoked", inspect the response body — when present, a machine-readable code field can disambiguate.

Gotchas

• Plaintext is shown once. The secret is displayed at create time; Nora never stores or re-displays it. Write it to your secret manager before you close the modal.
• Keys are instance-scoped. One key cannot span sandbox and production, even within the same org. Don't try.
• Never embed keys in client-side code. X-API-Key is a server- side credential. If it ends up in a browser bundle, mobile app, or public repo, treat it as compromised and rotate immediately.
• No cp-* headers. If you're migrating from a /cp integration, strip every legacy scoping header from your request code — /v2 doesn't read them.

See also

• Authentication (getting started) — the action-oriented "set up your first key" walkthrough
• Dashboard → API keys — UI for creating, listing, and revoking keys
• Error handling — the 401 responses you'll see