**Source:** https://heykiku.com/help/api-authentication

# Authentication and key management

All REST API requests authenticate via a Bearer token in the standard `Authorization` header. If you haven't minted a key yet, start with [getting started with the REST API](https://heykiku.com/help/api-getting-started).

## Header format

```
Authorization: Bearer kiku_live_<48-byte-base62>
```

The `kiku_live_` prefix identifies a production key. We only ever issue live keys today — there's no separate test environment, no `kiku_test_` keys for now.

## The key prefix is safe to log

Every API key has a short, non-secret `keyPrefix` (the first 18 characters). Logging the prefix is safe: it identifies *which* key made a request without exposing the secret. The prefix appears in API key listings and in our internal audit logs.

```
"kiku_live_abc123..."  ← log this
"kiku_live_abc123XYZ..." ← never log this
```

## CIDR allowlist

When you create or update a key, you can restrict it to a list of IPv4 CIDR blocks. Any request from outside the allowed ranges is rejected with a 403.

Use this for CI runners, server-to-server integrations, and any workload with a known origin. Set it to your office IP if you're testing locally; remove it before going to production.

Today we support IPv4 only — IPv6 CIDRs are rejected at issuance time with a clear error message.

## Expiry

Set `expiresAt` (ISO 8601) on a key to make it auto-expire. The earliest allowed expiry is the start of tomorrow (UTC) — an expiry of today or earlier is rejected at issuance. After the expiry instant the key behaves like a revoked key: requests fail with a 401 `API_KEY_INVALID`.

The dashboard flags keys expiring within 14 days so you can rotate before they die. Plan a rotation ahead of the expiry date — see [API best practices](https://heykiku.com/help/api-best-practices) for the recommended flow.

## Updating a key

`PATCH /api/api-keys/{id}` lets you change the **name**, **CIDR allowlist**, and **expiresAt** without rotating the secret. The scope is immutable post-creation — to change scope, revoke and re-create.

```bash
curl -X PATCH \
  -H "Authorization: Bearer kiku_live_..." \
  -H "Content-Type: application/json" \
  -d '{"allowedCidrs":["203.0.113.0/24"]}' \
  https://heykiku.com/api/api-keys/<id>
```

## Revoking a key

`DELETE /api/api-keys/{id}` revokes the key immediately. Revocation is permanent — there's no un-revoke. Returns 204 No Content on success.

If a key is compromised, revoke first and ask questions after.

## Break-glass revoke (owner)

If a team member leaves, the workspace owner can revoke **all** of that member's keys at once from the team page. Removing the member entirely (`Remove` action) also cascades a revoke automatically — every active key owned by that account stops working immediately.