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 your console. |
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 storefronts, customer portals, and admin tools — anywhere a real person is driving. See Sessions.
A server (API key). When your backend calls the platform with no user present — a sync job, a webhook handler, a scheduled task — you use an API key instead. Keys are created in your console, 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 sign-in: password, social providers, passkeys, and the second factor. You don't build login screens or store passwords.
- 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.