What happens to in-flight verifications when an API key is revoked?

Last updated May 20, 2026API

Revoking an API key on Valid Email Checker stops new authentication attempts immediately, but the answer for in-flight requests is more nuanced. The exact behavior depends on whether the request is a synchronous single-email verification or an asynchronous bulk task, and on whether your code is fetching the result or just kicked it off.

Single verification already accepted

When a /verify-single request reaches the API, the very first thing the function does is look up the key by hash and check its status. If the key was active at that moment, the request goes through the rest of the pipeline — credit deduction, provider lookup, response formatting — without re-checking the key in between. So a single-email verification that has already passed the initial auth gate will complete normally and return its result, even if you revoke the key one millisecond later in another browser tab.

The next request from your application, however, gets 403 API key is suspended — see what error does the API return when the key is revoked for the exact response. There is no graceful drain or wind-down period; the new state takes effect on the very next inbound request.

Bulk verification: split brain

Bulk is more interesting because it has two phases — task creation and result polling — and each goes through the auth gate independently.

PhaseBehavior after revocation
Task creation already acceptedThe background worker keeps processing the addresses on its own schedule. The task progresses to completion as if nothing happened.
Task creation in flight when you revokeIf the request had not yet hit the auth check, it now fails with 403 and the task never starts.
Polling get-results with the revoked keyReturns 403 immediately. You cannot retrieve results with that key.
Polling get-results with a different active keyWorks fine — task ownership is by user, not by the key that created it. Any active key on the same account can fetch the results.
Bulk tasks survive key revocation
If you created a 100,000-address bulk task and then revoked the key, the task does not get cancelled. It keeps running on the background worker, credits keep deducting from your account as addresses are processed, and the results are saved against your user ID. To fetch the results, either re-enable the original key or use any other active key on the same account.

What credits get deducted

Credits already deducted are not refunded by revocation. Single-verify requests deduct one credit at completion (or refund if the upstream provider returns unknown), and bulk tasks deduct per address as the worker processes them. Revoking the key partway through a 50k bulk task does not stop the worker from continuing to deduct credits for the addresses it processes — because, again, the task is bound to your user account, not to the key that initiated it.

Stopping a bulk task in progress

Revoking a key is not the right tool for cancelling a bulk task. The dashboard bulk page has a Cancel button on each running task — that genuinely halts the worker and stops further credit deductions. See how to verify a list in bulk for the dashboard flow. There is no public API endpoint to cancel a bulk task remotely as of this writing; that capability is on the roadmap.

Best practice when rotating a key

  1. Generate the new key first and roll it out to your application.
  2. Verify the new key is making successful requests (check the Credits Used counter on the new key row a few minutes later).
  3. Only then disable or delete the old key.

Doing the steps in the opposite order causes a brief window where requests fail with 403, which is rarely what you want. The Developer page lets you hold both keys active during the swap — there is no rate-limit penalty for the overlap.

Next steps