DEV Community: Yasir

Email Verification API on Apify: A Practical Guide

Yasir — Thu, 22 Oct 2026 09:44:27 +0000

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.

Open the Actor's API examples.

How to Verify an Email List Before Cold Outreach

Yasir — Thu, 22 Oct 2026 09:44:03 +0000

How to Verify an Email List Before Cold Outreach

Before you start an outreach campaign, check the email addresses you plan to use. An email verification tool can identify invalid addresses and flag other categories that need review, including disposable emails, shared inboxes, catch-all domains, and inconclusive results.

A useful verification workflow goes beyond running a check. You also need to interpret the results, connect them to the right contact records, and keep your campaign rules intact.

The Email Verifier & Deliverability Checker on Apify provides a Console interface and an API for this process. You submit addresses and receive verification statuses, scores, and individual flags.

Start with the list you actually intend to contact

Prepare the email addresses for the specific campaign. Keep a copy of the original contact records, including the identifiers you will need when updating a spreadsheet or CRM.

The Actor accepts an email list, rather than a whole contact database. If your source is a spreadsheet, extract the email column first. If another tool collected the contacts, pass the resulting addresses into the verifier.

Prepare spelling and formatting before submission. The Actor forwards the supplied strings without a separate trimming, deduplication, or typo-correction step.

Submit a small batch first

Open the Actor, paste a small selection of addresses, review the applicable pricing, and start the run. This gives you an opportunity to understand the output before processing the rest of the list.

The input accepts up to 1,000 entries per run. Larger lists should be split into separate runs. Account rules and spending limits can affect how much of a batch is processed, so keep a record of each run and the addresses submitted.

If you already use Apify, the cold outreach example task is a convenient starting point. Replace the demonstration addresses with your campaign list.

Read the verification status before choosing contacts

The main result category is in the status field. Other fields provide context, including the overall score, syntax result, disposable flag, role-account flag, and deliverability signals.

A practical review separates the results into three working groups:

Working group	Examples	What to do next
Candidates for your normal selection rules	`safe`	Apply your existing campaign and contact requirements
Results needing separate review	`catch_all`, `unknown`, `role_account`, `inbox_full`	Decide whether to hold, recheck, or handle them separately
Results generally unsuitable for the active outreach list	`invalid`, `disabled`, `spamtrap`	Exclude them until there is a justified correction or reassessment

Disposable addresses should be handled according to the purpose of your list. Their temporary nature may make them unsuitable for a lasting business relationship, even if they can receive a message at the time of checking.

A role account may belong to a legitimate shared inbox. A catch-all result describes domain behavior and does not confirm a particular person's mailbox. Avoid turning these distinct results into a single "valid" category.

Use the score as supporting information

The Actor returns overall_score on a scale from 0 to 100. Use it alongside the status and flags.

Do not interpret a score of 90 as a 90% probability of inbox placement. A missing score can also fall back to zero. Your selection rule needs to consider the available evidence rather than a score alone.

Some flags can contain an inconclusive value such as "None". If you use an automated filter, make sure that it understands those values instead of treating every nonempty string as true.

Export and join the results carefully

Export CSV or Excel for manual review, or retrieve JSON through the API. Apify datasets support these export formats.

Keep the verification fields alongside the correct contact record when updating your source system. Do not join rows only by their position: the response may contain fewer rows than the submitted list, and its ordering should not be assumed to match your original contact table.

Preserve unsubscribes and existing suppression rules when preparing the final campaign audience. A technical verification result does not tell you whether someone has asked to stop receiving messages.

Check whether the batch completed

Before calling a list "verified," review the run's status, saved results, and summary. A spending limit or interruption can leave a partial result set.

Avoid immediately submitting the full list again when you see fewer results. First determine what was saved and which contacts still need attention. A new run can create new charges.

Keep verification close to the decision

An email assessment reflects the time it was performed. Addresses and mailbox conditions can change, particularly when you are working with an older contact list.

When the list has been sitting for a while, reassess the contacts you actually plan to use. Choose the timing based on how quickly your data changes and how soon the campaign will run.

Address verification can help you identify avoidable address problems. Sending quality still depends on the wider campaign, including your relationship with recipients and how the sending system is operated.

Verify your next email list on Apify.