API keys

API keys is where you mint the bearer tokens that agents, integrations and custom dashboards use to call Saiku Cloud. You’ll come here once per integration, and then periodically to rotate.

The table lists every key with its name, the visible prefix, its status, when it was created, and when it was last used. That last-used column earns its keep: keys with no recent activity are usually keys nobody would notice you revoking, and keys with a lot of it are the ones worth rotating on a schedule.

Caution

A key acts on your tenant with the privileges of whoever created it. Treat each one as a secret — a password manager or your platform’s secret store, never source control, never a Slack message. If you think one has leaked, revoke it first and investigate afterwards.

Minting a key

1. Give it a name that says what it’s for: production-billing-agent, staging-bot, client-acme-integration. The name shows up in the audit log beside every request the key makes, so make it something you’d recognise at 2am.

2. Optionally list allowed cubes, comma-separated — Sales,HR. Leave it empty and the key can reach every cube the tenant has. Fill it in and the key is confined to exactly those cubes, enforced at the gateway before the request ever reaches the engine. This is the single most useful thing on the page: it’s how you give a partner’s agent one cube instead of your whole warehouse.

3. Click Create.

4. Copy the secret now. It’s shown once and never again. We keep the name and the prefix so you can identify the key later, but the secret itself is stored only as a hash — if you lose it, nobody can recover it, including us.

Keys look like sk_ followed by 32 hex characters. The dashboard shows the first few characters as the prefix, which is enough to match a key in the audit log against a row in this table without ever revealing the rest.

Using the key

Send it as a bearer token:

curl https://api.saiku.bi/me/tenant \
  -H "Authorization: Bearer sk_…"

The full reference — base URL, rate limits, error shapes — is in Authentication.

Rotation

Rotation is zero-downtime because both keys are live during the cutover:

1. Create a new key with the same allowed-cubes list and a name that distinguishes it — append -v2, -v3.
2. Deploy the new key to your integration.
3. Watch the Last used column. When the new key starts moving and the old one stops, the cutover is done.
4. Revoke the old key.

Revoking

Revoke on the row invalidates the key immediately — the next request using it gets 401 Unauthorized. No grace period, no undo. Deliberate, but instant when you need it to be.

One key per integration

The habit that pays off: one key per thing that calls you. If an agent is compromised you revoke its key and nothing else changes. When you want to know which integration made a particular request, the audit log’s key column answers it without detective work. And when a partner’s scope needs narrowing, you edit one allowlist instead of auditing a shared credential.

Keys are free to mint, so the only real cost is a slightly longer table.

Note

Rate limits are per tenant, not per key. Splitting traffic across several keys spreads the same budget rather than increasing it. Per-tier limits are in Authentication.

Related

• Authentication — using keys in requests.
• Audit log — every request, tagged with the key that made it.
• Usage — traffic and latency across all keys.
• MCP server — the guided path for pointing an AI assistant at your cubes.