# Authentication

Every Billing API request must carry a seller secret key:

```
Authorization: Bearer sk_live_4f6f...
```

Keys come in two environments, and the environment must match your account's
current mode: a Fynex seller account operates either in demo mode or live
mode, never both at once. While the account is in demo mode only `sk_test_…`
keys authenticate; after go-live only `sk_live_…` keys do, and the old test
key answers `401` from then on. There is no second, parallel dataset behind
the two prefixes — the API always returns your account's own billing records.

Keys are issued and rotated in the Fynex dashboard, on the **Integration**
page, and
are stored server-side only as SHA-256 hashes; a lost key cannot be recovered,
only regenerated.

Only `sk_test_…` and `sk_live_…` secret keys authenticate this public API.
Publishable `pk_…` keys, dashboard sessions, legacy seller tokens, cookies and
query-string credentials are rejected. This is a server-to-server API: never
call it from a browser or mobile app, and rotate or revoke a compromised key
in the dashboard immediately. No Billing-specific token store or session is
created; authorization reuses the existing hashed API-key record and its
active/revoked and environment checks.

Failure contract:

- `401` — the header is missing, malformed, or the key is unknown or revoked.
- `403` — the key is valid but the seller account is not active.

The seller account behind the key is the authoritative tenant: every object
this API returns belongs to that seller, and ids belonging to another tenant
answer `404`. Never embed secret keys in client-side code; calls must
originate from your servers.