API keys

Shown once

A key is displayed exactly once, at the moment you create it. Only a hash of it is stored, so nobody — including us — can read it back to you afterwards. The page will not show it again and support cannot recover it.

The practical consequence: copy it into your secret store before leaving the page. If you lose it, you do not recover it — you revoke it and create another. That is a two-minute operation, and it is the only safe design: a key a support process can retrieve is a key a support process can leak.

Where a key must never go

• Not in a query string. URLs end up in access logs, proxies, browser history and referrer headers.
• Not in client-side code. Anything shipped to a browser or a mobile app is readable by whoever runs it.
• Not in source control, not in a screenshot, not in a ticket.

Put it in an environment variable or a secret manager, and send it only as Authorization: Bearer ….

Scope it down

Each key carries its own scopes. A key that only needs to send should not be able to delete connections. Scopes are resolved live on every request, so tightening an existing key takes effect on the next call — you do not have to reissue it to narrow it.

Two keys are cheaper than one incident

There is no limit that forces you to share one key across everything. A separate key per deployment (staging vs production) and per job (a read-only reporting task vs a sender) means a leak is contained to one blast radius and can be revoked without taking the rest down.

Prefix

Keys are prefixed wsk_live_. Secret scanners can be taught the prefix, and a value in a log that starts with it should be treated as compromised and revoked immediately.