Skip to content
Arbitex Docs

Authentication

Every request to the Arbitex Gateway must carry a credential. The credential establishes which organization the request belongs to and which user identity it acts as — Policy Engine rules, quotas, and audit records all key off that identity.

Section titled “API keys (recommended)”

The primary credential is an Arbitex API key, prefixed arb_live_. Pass it as a bearer token:

Authorization: Bearer arb_live_your-api-key-here

This is the same header the OpenAI SDKs send by default, which is why pointing an OpenAI client at the gateway needs no auth-specific changes — just the base URL and the key.

Key properties:

  • Org-scoped + user-identified. A key belongs to one organization and carries the identity of the user who owns it. Rules that target specific users or groups apply based on that identity.
  • Created in the admin console under Users & Access → API keys. Keys are shown once at creation — store them in your secrets manager.
  • Revocable. Revoking a key in the console takes effect immediately; subsequent calls return 401 invalid_api_key.

Treat API keys as secrets: never commit them, never put them in client-side code, and rotate them on a schedule.

RS256 / JWT

Section titled “RS256 / JWT”

For deployments that issue their own short-lived tokens, the gateway accepts RS256-signed JWTs as bearer tokens:

Authorization: Bearer <jwt>

The token is verified against your organization’s configured public key (JWKS). The JWT’s claims establish the same org + user identity an API key would. Use this when you already have an identity provider minting per-user tokens and prefer short-lived credentials over long-lived API keys.

OAuth machine-to-machine (M2M)

Section titled “OAuth machine-to-machine (M2M)”

For service-to-service integrations with no interactive user, use the OAuth 2.0 client-credentials flow. A registered OAuth client exchanges its client ID + secret for an access token, which is then presented as a bearer token on gateway requests. The resulting identity is the service principal, and policy/quota/audit apply to it just as they would a user.

Register OAuth clients in the admin console; scope them to the minimum access the integration needs.

Choosing a method

Section titled “Choosing a method”
Method Best for
API key Most integrations, scripts, and SDK usage. Simplest to set up.
RS256/JWT When you already mint per-user short-lived tokens from your own IdP.
OAuth M2M Headless service-to-service calls with no interactive user.

All three resolve to an org + identity; everything downstream (DLP, policy, quota, audit) behaves identically regardless of how you authenticated.

Next steps

Section titled “Next steps”