# Email Verification Recheck Planner — Reuse Fresh Results (`mrtronson/email-verification-recheck-planner`) Actor

Reduce repeated paid email checks. Combine a new list with timestamped verification history to export only addresses needing rechecks, with freshness rules, duplicate suppression and conflict handling. $0.03 per plan for up to 50,000 emails.

- **URL**: https://apify.com/mrtronson/email-verification-recheck-planner.md
- **Developed by:** [Typed Diff](https://apify.com/mrtronson) (community)
- **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

$30.00 / 1,000 delivered plans

This Actor is paid per event. You are not charged for the Apify platform usage, but only a fixed price for specific events.

Learn more: https://docs.apify.com/actors/running/actors-in-store.md#pay-per-event

## What's an Apify Actor?

An Actor is a serverless cloud program that runs on the Apify platform. It has two run modes.
In Batch mode, an Actor accepts a well-defined JSON input, performs an action which can take anything from a few seconds to a few hours,
and optionally produces a well-defined JSON output, datasets with results, or files in key-value store.
In Standby mode, an Actor provides a web server which can be used as a website, API, or an MCP server.

Apify vocabulary and the platform model are defined once, in the agent quickstart at https://apify.com/agents.md.

## How to integrate an Actor?

If asked about integration, you help developers integrate Actors into their projects.
You adapt to their stack and deliver integrations that are safe, well-documented, and production-ready.

Do not guess an integration path. Every one of them is in the agent quickstart at https://apify.com/agents.md: the Apify MCP server, Agent Skills with the Apify CLI, the JavaScript and Python clients, the REST API, and the account-free path for an agent with no human to sign in. It also carries the rule on stating cost before the first paid run.

For examples already wired to this Actor's own input schema, see the [API](#api) section below.

Each client library has reference documentation the quickstart does not restate: [JavaScript/TypeScript](https://docs.apify.com/api/client/js/docs.md) (`npm install apify-client`) and [Python](https://docs.apify.com/api/client/python/docs.md) (`pip install apify-client`).

# README

### Send only the emails that need a new verification

**Turn a new email list and your previous verification results into a fresh `TO_VERIFY` queue.** Reuse recent results, remove repeated requests within the batch, and route uncertain or expired results back for checking.

This is a provider-independent pre-processing step. It does not connect to mailboxes, send email or claim to verify deliverability. Place it before a paid verification Actor or service; it returns the addresses that still need that service.

### Why use a verification recheck planner?

Recurring lead exports overlap. A generic deduplicator can remove identical rows, but it does not decide whether yesterday's verification is reusable or whether a newer uncertain result invalidated it. This Actor uses the latest timestamped result for each address and your freshness window.

The output explains every decision. Reused records include the prior status, timestamp, provider and age. Conflicting results at the same timestamp are sent for rechecking. Future timestamps, timestamps without time zones and malformed history rows are not trusted.

### How to use it

1. Paste the email addresses you are about to verify.
2. Paste previous results with `email`, `status` and `verifiedAt`. The optional `provider` field is preserved.
3. Choose a freshness window. The default is seven days.
4. Run and send the `TO_VERIFY` JSON array to your chosen verifier.

Use the Apify API to integrate this step with n8n, Make or your own pipeline. Scheduling is available through saved Apify tasks. No external API key is required.

### Input

```json
{
  "emails": ["sales@example.com", "sales@example.com", "new@example.com"],
  "previousResults": [
    {"email": "sales@example.com", "status": "valid", "verifiedAt": "2026-09-30T00:00:00Z", "provider": "your-verifier"}
  ],
  "maxAgeDays": 7,
  "reusableStatuses": ["valid", "invalid"]
}
```

`verifiedAt` must be an ISO timestamp with a time zone. Map your provider's corresponding fields to these names before submitting. You control which statuses can be reused; adapt `reusableStatuses` if your provider uses names such as `deliverable` or `undeliverable`. Unknown and catch-all statuses are rechecked by default.

### Output

| Field | Meaning |
|---|---|
| `action` | `reuse`, `verify`, `duplicate`, or `review` |
| `reason` | The precise decision rule |
| `duplicateOf` | Original input row index for a repeated address |
| `priorStatus`, `verifiedAt`, `ageDays` | Evidence from the previous result |
| `provider` | Source label supplied with that result |

The `TO_VERIFY` key-value record contains a unique array of addresses needing verification. The dataset preserves one decision per input row. Download JSON, CSV or Excel, or use the dataset API. `OUTPUT` contains all decisions, the queue and summary counts.

### Pricing

$0.03 per delivered plan, for up to 50,000 input emails and 100,000 previous results, within a 15 MB input limit. Platform usage is included in the published pay-per-event model. Invalid top-level input does not generate the billing event.

The planner can reduce subsequent verification requests. It does not refund upstream scraping charges, call a verifier automatically, or promise a particular saving. At $0.60 per 1,000 downstream checks, avoiding more than 50 checks would exceed the planner's $0.03 fee, before any other workflow costs.

### Matching and limitations

Domains are case-normalized and converted to IDNA. Local-part case, dots and plus tags are preserved to avoid merging potentially different mailboxes. Syntax screening is intentionally conservative, not a full RFC mailbox validator; unusual addresses are marked for review.

A reused historical result is not a fresh deliverability check. Addresses can stop working within the configured window. Choose the window and reusable statuses appropriate for your workflow. Only user-supplied data is processed; nothing is sent to an email service. Report issues or requested provider-field mappings in the Issues tab.

### Use existing Apify datasets

Select **Emails dataset** and/or **Verification history dataset** to reuse completed runs directly. Each selected dataset replaces its corresponding pasted array. Set the field paths if your source uses different names: for example, `data.email`, `result.status`, or `checkedAt`. The history timestamp must be the time the address was actually verified, not the time it was exported or copied. This Actor never invents a freshness timestamp. Missing or invalid history records are counted in the summary and do not establish verification.

Dataset reads are paginated and request READ access only to the selected resources. The emails dataset supports 50,000 rows and the history dataset 100,000 rows, each within 7 MB of the selected fields. A dataset that changes during the read, returns incomplete pages, or exceeds these limits fails clearly. No verification provider is called, and no email is sent.

# Actor input Schema

## `emailsDatasetId` (type: `string`):

Select a completed dataset. Overrides the corresponding pasted array. Only selected dataset read access is requested.

## `historyDatasetId` (type: `string`):

Select a completed dataset. Overrides the corresponding pasted array. Only selected dataset read access is requested.

## `emails` (type: `array`):

Email strings or objects containing email. Up to 50,000.

## `previousResults` (type: `array`):

Objects with email, status and verifiedAt (ISO timestamp with timezone), plus optional provider.

## `maxAgeDays` (type: `integer`):

Older results return to the verification queue.

## `reusableStatuses` (type: `array`):

Other statuses are always queued for checking. Case-insensitive.

## `emailField` (type: `string`):

Dataset field path, including nested paths such as data.email. Used only for selected datasets. Timestamps must represent the original verification time, with timezone.

## `historyEmailField` (type: `string`):

Dataset field path, including nested paths such as data.email. Used only for selected datasets. Timestamps must represent the original verification time, with timezone.

## `historyStatusField` (type: `string`):

Dataset field path, including nested paths such as data.email. Used only for selected datasets. Timestamps must represent the original verification time, with timezone.

## `historyTimestampField` (type: `string`):

Dataset field path, including nested paths such as data.email. Used only for selected datasets. Timestamps must represent the original verification time, with timezone.

## `historyProviderField` (type: `string`):

Dataset field path, including nested paths such as data.email. Used only for selected datasets. Timestamps must represent the original verification time, with timezone.

## Actor input object example

```json
{
  "emails": [
    "sales@example.com",
    "sales@example.com",
    "new@example.com"
  ],
  "previousResults": [
    {
      "email": "sales@example.com",
      "status": "valid",
      "verifiedAt": "2026-09-30T00:00:00Z",
      "provider": "example-verifier"
    }
  ],
  "maxAgeDays": 7,
  "reusableStatuses": [
    "valid",
    "invalid"
  ],
  "emailField": "email",
  "historyEmailField": "email",
  "historyStatusField": "status",
  "historyTimestampField": "verifiedAt",
  "historyProviderField": "provider"
}
```

# Actor output Schema

## `dataset` (type: `string`):

No description

## `queue` (type: `string`):

No description

## `report` (type: `string`):

No description

# API

You can run this Actor programmatically using our API. Below are code examples in JavaScript, Python, and CLI, as well as the OpenAPI specification and MCP server setup.

## JavaScript example

```javascript
import { ApifyClient } from 'apify-client';

// Initialize the ApifyClient with your Apify API token
// Replace the '<YOUR_API_TOKEN>' with your token
const client = new ApifyClient({
    token: '<YOUR_API_TOKEN>',
});

// Prepare Actor input
const input = {
    "emails": [
        "sales@example.com",
        "sales@example.com",
        "new@example.com"
    ],
    "previousResults": [
        {
            "email": "sales@example.com",
            "status": "valid",
            "verifiedAt": "2026-09-30T00:00:00Z",
            "provider": "example-verifier"
        }
    ]
};

// Run the Actor and wait for it to finish
const run = await client.actor("mrtronson/email-verification-recheck-planner").call(input);

// Fetch and print Actor results from the run's dataset (if any)
console.log('Results from dataset');
console.log(`💾 Check your data here: https://console.apify.com/storage/datasets/${run.defaultDatasetId}`);
const { items } = await client.dataset(run.defaultDatasetId).listItems();
items.forEach((item) => {
    console.dir(item);
});

// 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/js/docs

```

## Python example

```python
from apify_client import ApifyClient

# Initialize the ApifyClient with your Apify API token
# Replace '<YOUR_API_TOKEN>' with your token.
client = ApifyClient("<YOUR_API_TOKEN>")

# Prepare the Actor input
run_input = {
    "emails": [
        "sales@example.com",
        "sales@example.com",
        "new@example.com",
    ],
    "previousResults": [{
            "email": "sales@example.com",
            "status": "valid",
            "verifiedAt": "2026-09-30T00:00:00Z",
            "provider": "example-verifier",
        }],
}

# Run the Actor and wait for it to finish
run = client.actor("mrtronson/email-verification-recheck-planner").call(run_input=run_input)

# Fetch and print Actor results from the run's dataset (if there are any)
print(f"💾 Check your data here: https://console.apify.com/storage/datasets/{run.default_dataset_id}")
for item in client.dataset(run.default_dataset_id).iterate_items():
    print(item)

# 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start

```

## CLI example

```bash
echo '{
  "emails": [
    "sales@example.com",
    "sales@example.com",
    "new@example.com"
  ],
  "previousResults": [
    {
      "email": "sales@example.com",
      "status": "valid",
      "verifiedAt": "2026-09-30T00:00:00Z",
      "provider": "example-verifier"
    }
  ]
}' |
apify call mrtronson/email-verification-recheck-planner --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,mrtronson/email-verification-recheck-planner"
        }
    }
}
```

The hosted server signs you in with OAuth on first connect, so no API token belongs in this config. Clients without OAuth support can send an `Authorization: Bearer <APIFY_API_TOKEN>` header instead, using a token from API & Integrations in Apify Console (https://console.apify.com/settings/integrations).

## OpenAPI specification

Download the OpenAPI definition: https://api.apify.com/v2/actors/PAbOn3hg8knEpKdNc/builds/PORld8xJJgaZAakIo/openapi.json