Authentication

Every request to the OmiCloud API is authenticated with an API key sent as a bearer token:

Authorization: Bearer omi_live_k7Qw…

Keys and environments

Keys are created in the OmiCloud console under API keys and are shown once. OmiCloud stores only a hash; if you lose a key, revoke it and create another.

A key sent to the wrong host is rejected with 401 UNAUTHORIZED, the same as an invalid key. Nothing about the key leaks which environment it belongs to.

Scopes

Each key carries scopes. Keys created in the console get all four unless you narrow them:

A key without the needed scope receives 403 FORBIDDEN_SCOPE. A useful split is one key with sessions:write + transactions:read on your player-facing service, and a separate payouts:write key on the service that approves withdrawals.

Operator status

Your operator account can be paused by OmiCloud (for example while a compliance question is open). A paused operator's keys still authenticate — reads work — but writes return 403 OPERATOR_PAUSED with the reason in message.

Keeping keys safe

• Send keys only from server-side code. Never embed one in a mobile app or a browser.
• Rotate by creating a second key, deploying it, then revoking the first. Both are valid during the overlap.
• Revoking a key is immediate. Requests in flight with the old key fail with 401.
• The console shows lastUsedAt per key so you can find the ones that are dead.

What the key identifies

The key resolves to your operator. Every read is scoped to that operator automatically — there is no operatorId parameter anywhere in the API, and no way to see another operator's transactions. Transactions record which key created them (apiKeyId in the console) so you can trace activity per integration.