Skip to main content
Unkey stores every API key and root key as a SHA-256 hash, so you can issue and verify keys without keeping a homegrown key table. A copy of the database isn’t a list of working keys. This page covers that storage and what you can turn on around it.

​
How Unkey stores API keys

Unkey doesn’t store the API key. On create, it hashes the full key string with SHA-256 and stores the hash as standard base64, not hex. Verification hashes the key your user sent and compares the two strings. There’s no salt. The plaintext is returned once, in the create response, and isn’t kept. See the OWASP Secrets Management Cheat Sheet and the OWASP REST Security Cheat Sheet for hashing and storing secrets you only need to verify. SHA-256 here is a fast hash of a random key, not a password hash such as bcrypt or Argon2. If a keyspace must show a key again, you opt in to an encrypted copy beside the hash. The copy is AES-256-GCM, the keyring is the workspace, and only a root key with decrypt permission can read the key back. Verification still uses the hash. See Key storage and Recovering keys.

​
Should you build your own API key system?

You can. What moves to Unkey is generating the random key, storing only the hash, and checking it on each request. keys.createKey issues the key. keys.verifyKey checks enabled, expiry, credits, rate limits, permissions, and the IP allow list. If you already have hashes and the format matches, Migrating keys covers importing them. You still run your API, unless you deploy it on Compute. You still decide the HTTP status you return to your users. You stop maintaining the keys table, the hash comparison, and, if you use Unkey for them, the rate-limit counters and the monthly credit balance.

​
How Unkey protects the workspace

Two controls apply to the workspace itself, separate from how keys are stored. Access is scoped. A root key only works in the workspace that issued it, and every endpoint needs a specific permission. Dashboard users are either an admin or a developer. A developer who tries an admin-only action gets This action requires admin privileges. See Team. Changes are audited. Changes made in the dashboard appear in the audit log with who made them, the event, and a description. For example, renaming a workspace logs workspace.update. How long entries are kept depends on your plan. See Limits.

​
Security features you can use

Key storage

Hashing, verification, and the opt-in encrypted storage for recoverable keys.

GitHub secret scanning

What happens when a key is pushed to a public repository.

Delete protection

A flag that blocks deleting a keyspace, , or app until you turn it off.

Two-factor authentication

Enroll a second factor on your own account.

​
Reporting a vulnerability

If you find a security issue, email security@unkey.com with steps to reproduce. Don’t open a public issue or pull request. Reports about api.unkey.com and app.unkey.com are in scope. The docs site, the marketing site, and misconfigured self-hosted setups aren’t. The full policy is in SECURITY.md.
Last modified on October 22, 2026