Flintwake
Sign inStart free

Authentication

Keys, scopes and rotation without an incident.

Every call carries a bearer token. What that token may do, which environment it may touch and how you replace it are the three things worth getting right early.

Key format

Keys are prefixed so they are recognisable in a log, a screenshot or a secret scanner. The prefix tells you the environment class; the remainder is the secret.

Key shapes
fw_live_2Yc4hR8mQpL1vN6tZaKe3Xd7   # production
fw_test_5Dn9xA3zQw7eRt2yUi6oP1sD   # staging or sandbox
whsec_4f20a91c7b3e                # webhook signing secret

The secret is returned exactly once, on the response that creates the key. We do not store a recoverable copy. If you lose it, issue a replacement.

Send it
curl https://api.flintwake.com/v2/wakes \
  -H "Authorization: Bearer $FLINTWAKE_API_KEY"

Scopes

A key carries an explicit list of scopes. There is no implicit inheritance and no wildcard: a key that can write payments cannot read wakes unless you said so.

  • payments:read
  • payments:write
  • customers:read
  • customers:write
  • catalog:read
  • catalog:write
  • reports:read
  • webhooks:write
Issue one key per job.

A reporting worker needs reports:read and nothing else. When it is compromised — and one day something will be — the blast radius is the thing you already decided it was.

Environment isolation

Keys are bound to one environment at creation and cannot be moved. Identifiers are environment-scoped too, so cus_31ab in sandbox and cus_31ab in production are unrelated objects. A sandbox key asking for a production identifier gets resource_missing, never a cross-environment read.

Rotation

Rotation is three calls and one scheduled fourth. Issue the replacement, deploy it, confirm the old key has stopped being used, then revoke on a schedule.

Rotate a key
# 1. issue the replacement
curl -X POST https://api.flintwake.com/v2/api-keys \
  -H "Authorization: Bearer $FLINTWAKE_ADMIN_KEY" \
  -H "Content-Type: application/json" \
  -d '{"label":"Checkout service (2026-09)","environment":"production","scopes":["payments:write"]}'

# 2. deploy it, then 3. check the old key is idle
curl https://api.flintwake.com/v2/api-keys/key_7b41 \
  -H "Authorization: Bearer $FLINTWAKE_ADMIN_KEY"

# 4. revoke on a schedule
curl -X DELETE https://api.flintwake.com/v2/api-keys/key_7b41 \
  -H "Authorization: Bearer $FLINTWAKE_ADMIN_KEY" \
  -d '{"revoke_at":"2026-10-01T00:00:00Z"}'

The console shows a last-used time accurate to the second, which is how you know step three is safe. Try it in the interactive key manager on the console page.

If a key leaks

  1. Revoke it immediately. Revocation takes effect at the edge within two seconds.
  2. Issue a replacement with the same scopes and deploy it.
  3. Filter the request explorer by that key to see everything it did. Export the wakes if you need them for an incident record.
  4. Tell us at the security address if the leak involved our infrastructure rather than yours.
Revocation is not reversible.

There is no un-revoke. If you need a grace window, issue the replacement first and schedule the revocation — that is what revoke_at is for.

PreviousQuickstartNext Errors