How API Keys Are Stored (And What to Do If You Lose One)

If you've lost or misplaced a developer API key, the direct answer is: there's no way to retrieve it, and support can't recover it for you either, because the actual key value is never stored anywhere after the moment it's created. The only fix is revoking the old key and generating a new one. Here's exactly why that's the case and what's actually saved on the server side instead.

What Happens the Instant You Generate a Key

When you create a new API key, the system generates a random key value, prefixed so it's recognizable as an API key at a glance, built from cryptographically random bytes rather than anything predictable. That raw key is shown to you exactly once, in the response to the creation request, with an explicit note to copy it now because it won't be shown again. Before it's saved anywhere, the system runs it through a one-way hash and stores only that hash — the raw key itself is never written to the database, never logged, and never held in a way that could be retrieved later, by you or anyone with server access.

Why a One-Way Hash Instead of Just Storing the Key

A one-way hash is designed so that you can verify a value matches without being able to reverse the process and recover the original input. When you make an API request, the system hashes the key you send and compares that hash against what's stored — if they match, the request is authenticated. This means that even in the event of a full database compromise, an attacker gets a list of hashes, not usable API keys; they can't reverse a hash back into the original key value, so your actual credentials stay protected even if the storage layer itself is exposed.

This is the same reason the key is shown to you only once. If the system could show it to you again later, that would mean it was retrievable somewhere in storage, which would defeat the entire point of hashing it in the first place.

What's Actually Visible in Your Dashboard

Your list of API keys shows the name you gave each one, who created it, and when it was created and last updated — deliberately not the key value itself, since that was never retained. This is enough information to identify which key is which (useful if you've issued several for different integrations) and to see when a key was made, without any risk of the value leaking through the dashboard itself.

If You Lose a Key

Because the raw value genuinely doesn't exist anywhere after the creation response, losing it isn't a support ticket — it's not recoverable by design. The correct move is to revoke the lost key (which deletes its record entirely, immediately invalidating anything using it) and create a fresh one to replace it in whatever integration was using the old value. This is a slightly more disruptive process than a "forgot my key" recovery flow, but it exists precisely because the strong version of this security model has no way to answer "what was my key" after the fact — the tradeoff is deliberate.

What Deleting a Key Actually Does

Revoking a key removes its record entirely rather than deactivating it in place. Because authentication works by hashing an incoming key and looking for a matching stored hash, once the record is gone, there's nothing left for a request using the old key to match against — it fails immediately on the very next request, with no grace period or delay.

Frequently Asked Questions

Can I see a partial version of my key, like the last four characters, to help identify it later? Not currently — only the name and timestamps are retained for identification. If you're managing several keys, giving each one a clearly descriptive name at creation time is the practical way to keep track of which is which.

If I revoke a key by accident, can I get it back? No — revocation deletes the record, and the original key value was never stored to begin with, so there's nothing to restore. You'd generate a new key and update whatever was using the old one.

Does every API key have the same level of access, or can they be scoped? Keys are tied to your workspace as a whole rather than being scoped to specific permissions individually, so any valid key for a workspace can perform the actions your account is authorized for. If you're integrating with multiple external services, using a separate key per integration — rather than one shared key everywhere — makes it easy to revoke access for a single integration without affecting the others.