API keys

One key does two jobs: it authenticates the read-only reporting API, and it lets a headless agent connect to the MCP without a browser sign-in. Keys look like omni_sk_....

Create one

1. Open the account keys screen

Account, in the API keys card, next to the model keys.

2. Name it for where it will be used

"Client dashboard" or "Warehouse sync" tells you what breaks if you delete it. "API key 2" does not.

3. Copy the value now

It is shown once, at creation. There is no way to retrieve it afterwards, by design, so paste it into your secret store before closing the dialog.

4. Send it as a bearer token

Authorization: Bearer omni_sk_...

For a headless MCP client, the same value authenticates the connection in place of the OAuth flow, and carries the same tools and the same account boundary as a browser sign-in.

What a key can reach

Every project on the account that created it, and nothing beyond it. A request for a project on another account returns a 403 rather than a 404, so the boundary is explicit.

There is no narrower scope today. If a client needs data from one project only, put a filtered view in front of the API rather than handing over the key.

Rotating

In this order:

1. Create the new key.
2. Deploy it everywhere the old one is used.
3. Delete the old key.

Deleting takes effect immediately and breaks anything still using it, so doing this in the other order causes an outage you then have to explain.

Rotate on the usual triggers: someone with access leaves, a key appears in a repository or a log, or a client engagement ends.

Keys and seats are different access

Removing a teammate removes their console access. A key they created keeps working, because it belongs to the account rather than to them. When someone leaves, do both.