Skip to main content
Treat a key as compromised the moment it lands somewhere you didn’t put it — a public repo, a build log, a screenshot, a pasted stack trace, a shared terminal. Anyone holding a whk_ key can act as your organization, up to whatever that key is scoped for. The fix is short: revoke it. Everything below is detail around that one action.
We store only a keyed hash of your key, never the key itself. That’s the point — but it means we can’t show it to you again, and we can’t un-leak it for you. Revoking is the only remedy.

​
Revoke a leaked key

1

Open the dashboard

In the dashboard, go to your organization’s Settings → Credentials.
2

Find the key

Keys are listed by name and by the first few characters of the key — enough to tell one from another without revealing either.
3

Revoke it

Hit Revoke, then confirm. The key is marked revoked and dropped from the auth caches at once; in the rare case a cache eviction lags, it stops working within a few minutes.
Revoking can’t be undone, and anything still sending the old key gets a 401. If the key is serving production traffic, rotate first so you don’t take down the thing that depends on it.

​
Rotate without downtime

Revocation takes effect right away, so pulling a key that’s still in use will break whatever is using it. Put the new key in place before you take the old one away:
1

Create the replacement

On the same page, create a key with the same scopes — no more (see scopes). Copy it now; the secret is shown once.
2

Deploy it

Roll the new key out to your application, CI, or wherever the old one lived.
3

Confirm the new key works

A 200 from whoami means the key is valid and carries the scopes you expect:
The SDKs expose the same call as whoami() and the CLI as wbhk whoami. It confirms the key is good — not which key your app is sending, since two keys with the same scopes give identical answers. Make sure your deploy actually picked up the new value before you continue.
4

Revoke the old key

Now revoke it. Traffic still on the old key gets a 401.

​
Revoking a device

A device — a machine you’ve logged into with wbhk login — can mint keys of its own. Revoking a device cascades to every key minted under it, so if a laptop is lost or a CI runner is compromised, revoke the device rather than hunting its keys one by one.

​
Shrink the blast radius before it happens

A leaked key is a bad day. A leaked key with endpoints:write is a worse one.
  • Scope keys narrowly. A key only ever needs the scopes for its job. A read-only reporting job doesn’t need events:replay.
  • One key per consumer. Separate keys for CI, staging, and each service mean you revoke one thing, not everything.
  • Keep keys server-side. Never ship a whk_ key to a browser, a mobile app, or anything a user can read. The SDKs redact keys from their own errors and debug output — but that only helps once the key is already where it belongs.
  • Read from the environment. WEBHOOK_API_KEY in your secret manager, not a literal in source. Most leaked keys are committed keys.

​
Telling a real key from a placeholder

Every whk_ key is exactly 53 characters: the whk_ prefix, 43 random characters, and a 6-character checksum over those 43. If a string doesn’t have that shape, it was never a working key — so a whk_your_key_here in a README is nothing to worry about, and a scanner that flags it is wrong. The checksum lets us reject a malformed or truncated key before it ever reaches a lookup. It’s error detection, not security: the secret is the 43 random characters.

​
Reporting a leak you didn’t cause

Found a whk_ key that isn’t yours — in a public repo, a package, a paste? Tell us at security@webhook.co and we’ll take it from there. Please don’t use the key to check whether it works. Security issues in webhook.co itself go through our security policy.