API keys

API keys is where you mint the Bearer tokens that agents, integrations, and custom dashboards use to call api.saiku.bi. You’ll come here once for each integration you want to set up, and periodically thereafter for rotation.

The page lists every key in your tenant with a label, partial key ID, creator, creation date, and a last-used timestamp that updates in near-real-time. Useful for spotting keys that aren’t being used anymore (revoke them) and keys that are being used a lot (the right candidates for a rotation review).

Caution

An API key grants full access to your tenant under the role of whoever created it. Treat each one as a secret — a password manager or your platform’s secret manager, never source control. Rotate immediately if you suspect exposure.

Minting a key

1. Click Create key and label it. Use a name that describes what it’s for: production-billing-agent, staging-bot, client-acme-integration. Labels appear in the audit log so make them recognisable.

2. Click Create.

3. Copy the secret immediately. It only shows once. The dashboard keeps the key ID and label after this point but the actual secret is no longer recoverable — we don’t store it in reversible form.

4. Paste it into your integration’s secret store. Test end-to-end.

Using the key

Send the secret in the Authorization header:

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

The full reference lives at Authentication — base URL, rate limits, error shape, the lot.

Rotation

A clean rotation has zero downtime because both keys are valid during the cutover.

1. Create a new key with the same label as the old one (append -v2, -v3 so you can tell them apart).
2. Deploy the new key to your integration.
3. Confirm the new key is being used — the Last used column on the page updates within a minute or two.
4. Revoke the old key once you’re confident.

Revoking

Trash icon on the row, confirm. The key is invalidated immediately — the next request using it gets 401 Unauthorized. There’s no grace period and no undo, so revoke deliberately.

Rate limits

Rate limits are per-tenant, not per-key, so spreading load across multiple keys won’t give you more headroom — it’ll just spread the hits to your overall budget. See Authentication for the per-tier limits.

Per-agent keys

Best practice for any non-trivial deployment: one key per integration. If an agent gets compromised you revoke its one key without affecting any other. If you want to know which integration is responsible for a particular request, the audit log’s key-ID column tells you immediately.

The cost of this practice is roughly zero — keys are cheap to mint, and the dashboard doesn’t get unwieldy until you’re at the dozens.

Related

• Authentication — using keys in requests.
• Audit log — every request’s key is logged.
• Usage — per-key request volume.