Email Verification API on Apify: A Practical Guide
An email verification API lets your application submit addresses and receive structured verification results. With the Email Verifier & Deliverability Checker, you can build that step around an Apify Actor run.
The Actor accepts a single input field, emails, and saves its available results to a dataset. This makes it suitable for background contact checks, batch processing, and workflows that review a list before another system uses it.
The examples below illustrate the documented API sequence. They have not been executed against a paid live run as part of this article.
Prepare the email-list input
Send an array of between 1 and 1,000 strings:
{
"emails": [
"person@example.com",
"team@example.org"
]
}
The addresses above demonstrate the payload format. Replace them with the addresses you intend to verify.
The Actor accepts neither a CSV file URL nor complete CRM contact objects. Extract the email values first and retain any contact identifiers in your own system.
Start one Actor run
Store your Apify API token securely in the environment as APIFY_TOKEN. The following request starts a run and returns its run object. Running it incurs the Actor's applicable charges.
curl --fail-with-body --silent --show-error \
--request POST \
'https://api.apify.com/v2/actors/yasir-on-apify~email-verifier-deliverability-checker/runs' \
--header "Authorization: Bearer $APIFY_TOKEN" \
--header 'Content-Type: application/json' \
--data '{"emails":["person@example.com","team@example.org"]}'
Save data.id from the response. The response also includes storage identifiers such as data.defaultDatasetId. The asynchronous start endpoint returns before the verification work finishes.
Use the configured Actor run options and an appropriate spending limit for your job. Keep the token in server-side code or your automation platform's credential store.
Check the same run
Put the saved run ID in APIFY_RUN_ID, then request that run:
curl --fail-with-body --silent --show-error \
"https://api.apify.com/v2/actor-runs/$APIFY_RUN_ID" \
--header "Authorization: Bearer $APIFY_TOKEN"
Inspect data.status. Continue checking that run at a reasonable interval while it is active. Once it reaches a terminal state, handle the outcome: SUCCEEDED, FAILED, TIMED-OUT, or ABORTED. Use the returned run information when reporting errors.
Do not create another run just to check whether the first one has finished. Keep the run ID in your job record so a lost connection does not cause unnecessary resubmission.
For this Actor, a successful platform run can still have a partial application summary because a spending or access limit was reached. Review the SUMMARY record in the default key-value store and the saved results before marking the entire input batch complete.
Retrieve the verification dataset
After the run finishes, put the returned default dataset ID in APIFY_DATASET_ID:
curl --fail-with-body --silent --show-error \
"https://api.apify.com/v2/datasets/$APIFY_DATASET_ID/items?format=json&offset=0&limit=1000" \
--header "Authorization: Bearer $APIFY_TOKEN"
The dataset response is an array of result objects. Each result uses the existing 17-field structure, including email, status, overall_score, and the verification flags.
Apify supports JSON, CSV, and Excel dataset exports, among other formats. The API supports pagination when you need to retrieve more data. For this Actor's current per-run input limit, the request above asks for up to 1,000 items.
Interpret fields before automating decisions
A safe status, a role_account status, and an unknown status should not be treated as interchangeable. Preserve the original category and apply the contact rules for your workflow.
The output retains compatibility values. A check can be a boolean, a number, or a string such as "None". Avoid programming shortcuts that treat every nonempty value as a positive result.
Likewise, an integer score is not a calibrated delivery probability. Use the score with the status and available checks.
Join results back to your source records
Keep the input batch and the original contact identifiers in your application. Match using an appropriate email comparison rule and preserve any one-to-many relationship when several records share an address.
Do not attach results to CRM contacts by array position alone. The result count may be smaller than the input count, and the returned order should not be assumed to preserve your original contact-table ordering.
The Actor does not perform a separate input deduplication or canonicalization step. Any cleanup or contact merging in your application is a separate workflow decision.
Choose an appropriate execution pattern
A background run is a practical default for bulk verification. It allows your application to track progress without keeping one request open for the entire job.
Apify also provides a synchronous run-and-dataset endpoint, but its documented HTTP wait limit is 300 seconds. Longer runs can exceed that limit. Do not assume that an HTTP timeout means the underlying work never started.
For an interactive signup form, measure latency and design fallback behavior before relying on a complete Actor run in the user's request path.
Use the same contract with connected agents
Connected agents can call eligible Actors through Apify's MCP server.
Provide the exact Actor identifier, the email list, the input limit, and the meaning of uncertain results. Ask the agent to retrieve the actual dataset before summarizing outcomes.
For example:
Use the Apify Actor yasir-on-apify/email-verifier-deliverability-checker to verify the email list I provide. Show the applicable cost and input before starting the run. After it completes, summarize the returned statuses and provide the dataset link. Keep catch-all and unknown results separate from safe results.
This prompt works only in an environment with an appropriate Apify connection and authorization. It does not install a connector or make the tool available in every AI application.
Top comments (0)