Authentication
Every request to the platform goes through one gateway at https://api.revenexx.com, and every request has to answer two questions: who is calling and which tenant the call is for. Authentication is how you answer the first; the tenant header answers the second. Both are part of Customers, the platform's identity surface, and both ride as request headers the gateway checks before anything else runs.
You send one credential and one tenant slug on each call:
| Header | What it carries | Where it comes from |
|---|---|---|
Authorization: Bearer <JWT> | A signed token for an interactive user. | Issued by ID when a user signs in. |
X-Revenexx-Api-Key: rvxk_… | A scoped key for server-to-server calls. | Created in Cockpit. |
X-Revenexx-Tenant: <slug> | Which tenant the request applies to. | Your tenant's kebab-case slug. |
Send X-Revenexx-Tenant on every call. For the credential, send a Bearer token or an API key — never both, and never an API key from a browser.
Two ways to authenticate
A signed-in user (Bearer token). When a person uses your app, they sign in through ID and your app receives a JWT. You send that token as Authorization: Bearer <JWT> on each call. The gateway validates the token's signature against ID and then acts as that user. Use this for admin tools, internal apps and back-office integrations, where a staff member or operator is driving. See Sessions. A buyer on a storefront or customer portal does not sign in through ID: your server signs them in through the customer routes and keeps calling with its API key. See Sign a buyer in from your server.
A server (API key). When your backend calls the platform on its own — a sync job, a webhook handler, a scheduled task — or for a buyer who is signed in to your storefront, you use an API key instead. Keys are created in Cockpit, carry a fixed set of scopes, and start with rvxk_. You send the key as X-Revenexx-Api-Key. Keep keys on the server; never ship one to a browser or a mobile app. See API keys.
What's the platform's job, what's yours
The platform handles the parts that are easy to get wrong:
- ID runs staff sign-in: password, social providers, passkeys, and the second factor. You don't build login screens for staff or store their passwords.
- For buyers, the customer routes check the password, hold the account and the session, and send the confirmation and sign-in mails. Your storefront shows the forms and keeps the session on its server.
- The gateway validates every credential and rejects anything expired, malformed, or out of scope before it reaches your data.
- Data is automatically scoped to the tenant on the request, so one tenant's calls can't read another's.
Your job is the integration:
- Send users to ID to sign in, and attach the token you get back to API calls. See Sessions.
- Create and rotate API keys for your servers, scoped to what each one needs. See API keys.
- Register the social providers you want to offer, if any. See Social sign-in.
In this section
- Sessions — sign a user in through ID and use their token.
- API keys — create and use scoped keys for server-side calls.
- Social sign-in — let users sign in with Google, GitHub, and other providers.
- Multi-factor authentication — add a second factor and passkeys.