Start here

API keys authenticate requests to the REST API at https://app.orbitid.com/api/v1. Every key belongs to one environment.

Check how this app handles its OrbitID API key. Follow https://orbitid.com/docs/api-keys.md

1. Read the key only from ORBITID_API_KEY, on the server, so it never reaches the client bundle.
2. Search the repo for orb_live_ and orb_test_ strings and tell me where they are.
3. Call https://app.orbitid.com/api/v1 through one shared client with "Authorization: Bearer".
4. Treat a 401 as a revoked key: log it clearly instead of retrying.
5. List what you changed and any key I should rotate.

Create a key

Open the environment in the dashboard, go to API keys, click Create key and give it a name (for example backend or ci). The full key is shown once; store it in your secrets manager. The dashboard only keeps the prefix, the creation date and when the key was last used.

Use a key

Send the key in the Authorization header:

curl https://app.orbitid.com/api/v1/sso \
  -H "Authorization: Bearer orb_live_..."

A key can only see and change data in its own environment. The product of each request is derived from the key, so you never pass it, and a Sandbox key can never touch Production connections.

Rotate or revoke a key

Create a new key, deploy it, then revoke the old one from the same page. Revoking is immediate: requests with a revoked key get 401 Unauthorized.

What the API covers

• POST, GET, PATCH, DELETE /api/v1/sso – SSO connections (SAML and OIDC).
• POST /api/v1/portal/links – Admin Portal links.
• /api/v1/dsync – directories, and the users, groups and events synced into them.
• /api/v1/sso-traces – SSO logs.

The OAuth endpoints under /api/oauth and the SCIM endpoints under /api/scim/v2.0 do not use API keys: the first are called by your users' browsers and by your OAuth client, the second by your customers' directories with a per-directory bearer token.