Email verification in Python with safe retries
A useful Python integration treats verification as a tabular, billable operation. Keep the Api token on the server, use an request identifier tied to the logical job and preserve unknown results. A network exception should not cause a new charge simply because the client generated a new identifier.
Open the relevant free tool →Make retries safe for the same operation
Prepare the request
Read EMAILVALIDLY_API_KEY from your server configuration or secret manager. Send JSON to the authenticated verification endpoint with a Bearer token. Use a request identifier containing 8–100 supported characters. Store that identifier with the job before the network call so a worker restart can retry the same operation rather than inventing another one.
Handle response classes deliberately
A 200 response contains a completed result or a replay. A 400 indicates input that needs correction. A 401 requires credential or plan attention, and a 402 means the account lacks credits. For 429, observe Retry-After. For a network failure or an in-flight 409, retry with the same identifier and bounded backoff. Do not convert these failures into an invalid email result.
Keep status and checks
Store the returned status, timestamp and relevant individual checks. The score is a heuristic summary, not a probability. A null mailbox field must remain null rather than becoming false during conversion to a database boolean. If your application needs ownership confirmation, implement that separately after the technical check.
Bound the worker
Set request timeouts and concurrency limits. Keep a maximum attempt count and move persistent failures to a review queue. Avoid printing API keys or complete contact lists in logs. For a bulk import, report how many records were completed and how many remain pending so a partially processed file cannot look finished.
Test before connecting production data
Use a local mock HTTP server to exercise 200, 402, 409, 429 and timeouts without spending verification credits. Confirm that retry attempts reuse the same identifier and that a changed input does not reuse it. Then run a small authorised live sample. Paid API access becomes available when billing is activated; do not hardcode a fake success path while credentials are missing.
Worked example
A request checks pat@example.com. If the connection fails, retry with the same request identifier. If the response says unknown, save it for review. See the API documentation for the exact HTTP headers and runnable code.