Mails.so

Mails.so is an email validation API for keeping lists clean before you send. Agents validate a single address in real time or submit a batch job and collect the results when it finishes.

Verified 3 actions API key available

Mails.so website Platform Documentation Capability data verified 2026-08-19

A new prospect address enters the pipeline from research or a form

Validate Email returns the verdict, the reason behind it, and the six checks

Agent reads the reason code, not only the verdict

Addresses whose reason is a timeout or a failure to connect are set aside for retry

Deliverable addresses are written to the sequencer and cleared to receive mail

Counts by reason are posted to the outreach channel

The outreach owner decides what happens to the risky cohort behind catch all domains

What This Integration Enables

Mails.so is a validation API with an unusually honest verdict vocabulary, and that is the whole argument for it. Its result is one of four values rather than a boolean: deliverable, undeliverable, risky, or unknown. Alongside it comes a reason, and two of the reasons describe a failure to reach the mail server rather than anything about the address. The vendor's own worked example makes the point better than any explanation: three addresses on the same domain, in the same job, and two of them come back unknown on a timeout while the third comes back deliverable. Nothing about those two addresses was wrong. The check simply did not complete.

FlowRunner agents treat that structure as the feature it is. Single validation runs inline while a record is being created, returning the verdict, the reason, a score, and six individual checks. Batch validation submits many addresses as one job and collects the results when the job reports itself finished, which is the only completion signal the API offers. This API also delivers refusals inside a successful response rather than in the status code, so an unpaid or rejected batch can read as an empty result to anything that only checks the status line. The connector raises those as errors instead, which is what keeps a list that was never validated from being reported as a list that came back clean. Around all of it, human-in-the-loop steps hold the decisions where the API's honesty leaves a real question open.

Without FlowRunner

Four outcomes flattened into two Anything not deliverable gets treated as bad, including the checks that never completed

Retryable failures thrown away A slow mail server on the afternoon of the sweep costs you real prospects permanently

Batch spend decided by whoever ran it A list is submitted for validation without anyone sizing it or deduplicating it first

With FlowRunner

The reason travels with the verdict Invalid format, invalid domain, catch all, and timeout are handled as the different things they are

Unreachable is a state, not a judgment Timeouts and connection failures are queued for a later attempt rather than suppressed

Batch composition reviewed before submission The agent proves the list size and what it removed, and a person authorizes the job

Use Case Scenarios

Validation at the moment of research

A researcher or an enrichment step produces a new prospect address, and the agent calls Validate Email before the record is written anywhere. Deliverable results flow straight into Instantly or Apollo with the score stored on the record. Undeliverable results with a format or domain reason never reach the sequencer at all. Risky results are written but held out of the active sequence, and unknown results are put on a short retry timer. The rep sees a list where every address has already been through this, and where the reason for every exclusion is recorded next to it.
A list cleaned before it becomes a campaign

A purchased or inherited list lands in Google Sheets. The agent deduplicates it, removes anything already on the suppression list, and reports what is left. Once the submission is authorized, Create Batch Validation submits the job and the agent polls Get Batch Validation until the job reports itself finished, ignoring the partial results that come back before that. It then writes four tabs rather than two: deliverable, undeliverable, risky with the catch-all reason called out, and unknown with the timeouts separated from the connection failures. The campaign is built from the first tab. The fourth tab is scheduled to run again rather than deleted.
Retry as a first-class path

A weekly job re-runs Validate Email against everything that previously returned unknown with a timeout or a connection failure. Most of them resolve on the second attempt, because the original result was about the server's availability that afternoon and nothing else. The ones that resolve are promoted to the active list and a note is posted to Slack with the recovered count. The ones that fail the same way three times in a row are escalated for a human look, since a domain that never answers is a different problem from a domain that was busy.

Human-in-Loop Highlight

Create Batch Validation is the operation to stop in front of, and the reason is what the connector does not have. Mails.so publishes three routes: validate one address, create a batch, read a batch. There is no cancel, no stop, and no partial refund. Submitting the job commits the entire list against the account's plan in a single call, and the only lever afterward is to read the result you already paid for.

So the hygiene agent does all the reversible work first and then waits. It posts: "List assembled for batch validation. 41,200 rows in, 3,800 exact duplicates removed, 1,140 already on the suppression list removed, 36,260 to submit. 9,100 of those were validated within the last 60 days and could be excluded. Submit 36,260 or 27,160?" The list owner picks. The agent then submits once, polls until the job reports itself finished, and never reads a partial result as a final one. Deduplicating a list is arithmetic and the agent should own it. Deciding how much of a finite plan a single job consumes is not arithmetic, and there is no operation here that undoes the answer.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via preferred channel

Human decides

Agent resumes with decision

Agent Capabilities

3 actions

Validation

Validate Email Checks one address in real time and returns the verdict, the reason behind it, a score from 0 to 100, whether the address is on a consumer provider, and the six individual checks covering format, domain, MX, blocking, catch all, and generic addressing. The connector adds a plain deliverable flag so a flow branches without comparing strings. Used inline at the point a record is created, and for retrying addresses whose earlier check timed out.

Batch Validation

Create Batch Validation Submits many addresses as a single asynchronous job and returns the job record with its size. Requires a paid plan. Used for list cleaning at volumes where a per address call would be impractical, and the one operation on this connector that commits real spend in a single call.
Get Batch Validation Reads a submitted job along with its per address results. The connector adds a finished flag so a flow does not have to test a timestamp for null, which matters because results read before the job completes may be partial. Used to poll a running job and to collect the outcomes once it is done.

Frequently Asked Questions

What can FlowRunner do with Mails.so?

FlowRunner agents can run Validate Email, Create Batch Validation, and Get Batch Validation in Mails.so.

Does connecting Mails.so to FlowRunner require OAuth?

No. Mails.so connects to FlowRunner with an API key, no OAuth flow required.

Can Mails.so trigger a FlowRunner workflow automatically?

Mails.so doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with Mails.so

Free plan, no card required. Connect in minutes.

Start Building Free Talk to us