API keys

Create scoped keys for server-to-server calls and send them with the X-Revenexx-Api-Key header.

An API key authenticates your server to the platform when no user is signed in — a sync job, a webhook handler, a scheduled task, a backend that talks to the API on its own. The key carries a fixed set of scopes that limit what it can do, and it identifies one tenant. Keys start with rvxk_.

Use a key only on a server. A key is a long-lived secret with standing access; if it reaches a browser or a mobile app, anyone can read it. For anything a real person drives, sign the user in and use their token instead — see Sessions.

Create a key

You create and manage keys in your console:

  1. Open your console and go to API keys.
  2. Click Create key.
  3. Give it a name that says where it runs, for example order-sync-prod.
  4. Select the scopes it needs — grant only the ones that job uses.
  5. Create the key and copy it. The full value is shown once; store it in your secret manager.

Create a separate key per job or service rather than one shared key. When you rotate or revoke one, the others keep working, and a leaked key affects only its own job.

Use a key

Send the key as X-Revenexx-Api-Key, with your tenant slug. With the Web SDK — running server-side — set it on the client:

Node
import { Client } from "@revenexx/sdk";

const client = new Client()
  .setEndpoint("https://api.revenexx.com")
  .setTenant("<TENANT_SLUG>")
  .setApiKeyAuth("rvxk_...");

Or send the headers directly over HTTP:

cURL
curl https://api.revenexx.com/v1/products \
  -H "X-Revenexx-Api-Key: rvxk_..." \
  -H "X-Revenexx-Tenant: <TENANT_SLUG>"

Load the key from an environment variable or a secret manager — never hard-code it in source and never commit it to git.

Scopes

Each key carries scopes that decide which parts of the API it can reach. A call that needs a scope the key doesn't have is rejected with 403 Forbidden. Grant the narrowest set that does the job: a key that only reads orders doesn't need write access to customers.

If a call fails with 403, check the key's scopes in your console before changing your code — the request reached the platform and was understood; it just wasn't allowed.

Rotate and revoke

Keys don't expire on their own, so rotate them on a schedule and whenever someone who had access leaves:

  1. Create a new key with the same scopes.
  2. Deploy it to the job that uses it.
  3. Revoke the old key once nothing uses it.

If a key leaks, revoke it immediately in your console. Revocation takes effect within seconds, and any later call with that key fails with 401 Unauthorized.

Troubleshooting

  • 401 Unauthorized — the key is missing, mistyped, or revoked. Confirm the header is X-Revenexx-Api-Key (not Authorization) and that the key is still active.
  • 403 Forbidden — the key is valid but lacks a scope the call needs. Add the scope to the key, or use a key that has it.
  • Wrong or empty results — check X-Revenexx-Tenant is the right slug.

What's next

  • Sessions — authenticate a signed-in user instead.
  • Web SDK — the typed client used in the examples above.
  • PHP SDK — the same client from PHP.
Was this page helpful?