Authentication
One header, on every request:
Authorization: Bearer nk_live_2YN0...There is no OAuth flow, no session and no cookie. A key is a bearer credential: anyone holding it is you, so keep it on a server and out of browsers, mobile binaries and repositories.
Key format
A live key is nk_live_ followed by 64 hexadecimal characters. Nothing else is accepted, so a truncated or re-wrapped key fails as unauthorized rather than silently reading as a different key.
Only a hash of the key is stored. We cannot recover a key for you, and neither can anyone who reaches the database.
The key is shown once
The console shows the full key on the screen that creates it and never again. Copy it into your secret manager at that moment. If it is lost, revoke it and create another; that is cheaper than any recovery we could offer.
Rotation and revocation
Create the replacement first, deploy it, then revoke the old one. Both keys work while you cut over, so there is no window where your integration is down.
Revocation takes effect on the next request. A revoked key returns 401 unauthorized, exactly like an unknown one, so a leaked key discloses nothing about whether it was ever valid.
What a rejection looks like
HTTP/1.1 401 Unauthorized
Content-Type: application/json
X-Request-Id: 6f0b1f3a-2b0e-4b1e-9a2f-9c2a1d5f7e10
{"error":{"code":"unauthorized","message":"Missing or invalid API key."}}Every response, including a rejection, carries X-Request-Id. Quote it when you write to us and we can find the exact request.
403 forbidden is different from a 401. The key is real; it just does not carry the scope this endpoint needs. See Scopes and plans.