API keys

API keys let you call the platform's HTTP API from your own scripts, CI jobs, or internal tools. Use them for things like uploading sources from a scheduled job, fetching tracker results into a Slack bot, or kicking off a skill from another service.

Where to find this

Go to /settings/api-keys (from account menu → API keys).

The page is titled API keys with the description: "Bearer tokens for non-browser callers — MCP server, scripts, Activepieces flows. The token is shown once on creation; we only store its hash."

You can create keys for yourself only. To create a key for a service or shared user, sign in as that user first.

What's on the API keys screen

Your keys (N active) section header with active key count.
+ New API key button (top-right of the section).
Below: list of your keys, or the empty state — "No keys yet. Create one above to use the API outside the browser."
Each existing key row shows: name, prefix (aie_a3f1...), creation date, last-used timestamp, expiry, and a revoke (trash) icon.

Creating a key

Click + New API key.
Give it a name (descriptive — "Daily upload cron", "QBR report generator").
Optionally set an expiry: 1 to 3650 days. Leave blank for no expiry.
Click Create.
Copy the token immediately. The full token is shown only once. After you close the dialog, only the prefix (e.g. aie_a3f1...) remains visible. The platform stores only a hash of the token, not the token itself.

The token format is aie_<8 hex>_<43 base64url>.

Using a key

Pass it as a Bearer token in the Authorization header:

GET /api/projects HTTP/1.1
Host: insights-engine.kapiva.in
Authorization: Bearer aie_a3f1b2c4_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

The platform updates the key's last-used timestamp on every call so you can spot inactive keys.

What a key can do

A key inherits the full permissions of the user who created it. If you're an Admin, your key is an Admin key. If you're a Member, your key is a Member key. If a teammate uses your key, they have your access.

Status: gap. The platform stores per-key scopes in the database, but the runtime currently grants every key its owner's full permissions regardless of the scope list. Scope enforcement is on the engineering roadmap. Treat API keys as broad-access credentials for now and rotate them frequently.

Restrictions

Keys can only be created and revoked through the browser UI by a signed-in user. You cannot use an API key to mint another API key.
Keys cannot do administrative actions on your behalf that the UI also can't — e.g. they can't promote users to Owner.
Failed-auth attempts (wrong key, expired key, revoked key) are not currently rate-limited at the application layer. Your operator's load balancer should provide rate limiting.

Rotating a key

There is no automatic rotation. To rotate:

Create a new key with the same name + "(v2)".
Update your service to use the new key.
Verify the old key's last-used timestamp stops advancing.
Revoke the old key.

Revoking a key

Click the trash icon next to the key's row. The key stops working immediately. The action is logged to the audit log as api_key.revoke.

You cannot un-revoke a key. Create a new one.

Best practices

Name keys descriptively — "DailyUploadCron-v2" beats "Key 3".
Use short expiry windows for ephemeral jobs (e.g. 30 days for CI).
Never check API keys into git. Use your secret manager.
Revoke promptly when a team member leaves or when a service is decommissioned.
Don't share keys. Create a key per consumer so revocation has a small blast radius.

Auditing key use

Every key creation and revocation appears in the audit log with the actor email and timestamp. Day-to-day API calls themselves are not (yet) individually audited — see the audit-log page for what's captured.

On this page