What's the difference between revoking and deleting an API key?
On the Developer page, the three-dot menu next to each Valid Email Checker API key shows two destructive actions: Disable and Delete. Both stop the key from authenticating new API requests, but they differ in what stays behind, whether you can roll the change back, and how the row behaves afterward.
Side-by-side comparison
| Behavior | Disable (revoke) | Delete |
|---|---|---|
| Stops new requests | Yes, immediately | Yes, immediately |
| Row visible in table | Yes, status badge turns grey "Disabled" | No, row disappears from view |
| Reversible | Yes — click Enable from the same menu | No, irreversible from the UI |
| Usage history preserved | Yes | Yes (soft-delete behind the scenes) |
| Credits used counter retained | Yes | Yes, but not visible to you |
| Counts toward active key list | No | No |
How disable actually works under the hood
Disable flips the status column on the key row from active to disabled. The next request that hits /api/verify-single (or any other endpoint) with that key returns 403 API key is suspended immediately — see what error does the API return when the key is revoked for the exact response shape. The row stays in your Developer table with a grey "Disabled" badge so you remember it exists, and the actions menu now offers an Enable option that flips the status back to active.
Use disable when you suspect a key has been exposed but you are not 100% sure, or when you are pausing an integration for maintenance and plan to bring it back later. Re-enabling restores the original key value — no regeneration needed.
How delete actually works
Delete is a soft delete on our side. The row is marked status = deleted and disappears from the Developer table — but the underlying record stays in the database with all its usage history attached, because we tie billing records to it. There is no Restore option in the Developer UI. If you genuinely need a previously-deleted key back, you cannot recover the old value (we hash keys with SHA-256 and never store the plaintext), so just generate a fresh one.
When to choose which
- Key leaked publicly (commit, screenshot, Slack DM) — delete it. The key is compromised; you do not want anyone re-enabling it accidentally. Generate a fresh key for the integration that was using it.
- Pausing an integration for the weekend — disable. Easier to re-enable Monday morning than to update your secret store with a new value.
- Decommissioning an old test environment — delete. The key is no longer needed and cluttering the table makes it harder to spot active keys.
- Employee with API access left the company — depends. If they did not export the plaintext value, disable is enough. If you are unsure what they may have walked away with, delete and rotate.
Suspended vs. disabled
You may also see "Suspended" appear as a status on the Developer page — that is different from Disabled. Suspended means the Valid Email Checker abuse-protection system flagged the key (for example after repeated rate-limit hits or suspicious traffic patterns) and the action menu shows a red banner explaining the reason instead of an Enable button. Contact support if you believe a suspension was triggered in error; see how do I contact support.
Next steps
Related questions
Still stuck? Email support