Skip to content
RebelCore Docs

API users

An API user is a credential pair (username + password) that authenticates a non-human caller — your application, an automation script, a third-party service. API users belong to your customer just like portal users do, but they don’t sign in to the UI. They’re created from the portal and used only against the API endpoints.

Who can create them

Only the Customer Super Admin can mint API users. This is intentional — API credentials don’t expire on idle and can be redistributed inside an organisation, so the privilege required to create one is higher than the privilege to add a regular portal user.

If you don’t see the option described below, you don’t have super-admin access. Ask whoever owns the customer in your organisation.

Creating an API user

  1. Sign in to the portal as the Customer Super Admin.
  2. Open the Users page.
  3. Click the green + button in the bottom-right corner.
  4. Choose API User from the popover.
  5. The portal mints credentials and shows them in a one-time dialog.

The dialog displays:

  • Username — a synthetic email address ending in @api.rebelcore.local. It’s not a real mailbox; it’s how the API user is identified internally.
  • Password — a 48-character random string.

Where to store the credentials

The API user’s password is functionally equivalent to a service-account secret. Treat it that way:

  • Do put it in your secret manager (Azure Key Vault, AWS Secrets Manager, HashiCorp Vault, GitHub Actions secrets, etc.).
  • Do scope it to the smallest set of services that need to call the API.
  • Don’t check it into source control.
  • Don’t ship it in browser JavaScript or a mobile app — anyone who inspects the bundle can read it.
  • Don’t email it or paste it into chat. Hand it over via your secret-distribution process.

Rotating credentials

There is no UI to reset an API user’s password. To rotate:

  1. Mint a new API user with the same role.
  2. Update your application to use the new credentials.
  3. Once the old user has stopped being called, deactivate it from the Users page.

Deactivating an API user blocks all future /authorize calls immediately. Tokens already issued continue to work until they naturally expire (24 hours from issue).

Lifecycle and limits

  • Number of API users — there’s no fixed cap. Create as many as your integration model needs (one per service is reasonable; per-environment is also reasonable).
  • Status — same statuses as portal users. An inactive API user can’t authenticate.
  • Audit — every API user creation, deactivation, and call is logged on the activity page.

When to create a separate API user vs. reuse one

A new API user per:

  • Environment (dev, staging, production) — so a stolen dev credential doesn’t grant access to production data.
  • Application or service — so revoking one doesn’t break the others.
  • Tenant in your own product — if you’re a SaaS reselling RebelCore™ inference to multiple end-customers, each end-customer needs their own API user mapped to their own RebelCore™ customer.

A single API user is fine for a small internal automation. For anything customer-facing, create one per surface.

Next