ValidEmail

Validate email addresses in real time with ValidEmail.co, returning a deliverability verdict per address. Agents screen an address at capture rather than discovering the problem on send day.

5 actions API key available

Platform Documentation ↗ Capability data verified 2026-07-31

A blacklist monitor check returns a listing on the primary sending domain

Agent re-reads the monitor with Get Blacklist Monitor to confirm which blocklists are involved

Agent looks up the campaigns scheduled to send in the next twenty four hours

Agent opens an incident record with the affected domain, the listed blocklists and the exposed campaigns

Deliverability owner decides whether to hold the scheduled sends or let them run

What This Integration Enables

ValidEmail.co has a deliberately narrow surface, and the narrowness is the argument. Five operations cover two moments: the address you are about to accept, and the day a blocklist decides your sending infrastructure is a problem. There is no batch pipeline here and no toxicity model. There is one synchronous verdict per call, rate limited and credit metered, which makes it a gatekeeper at the door rather than a scrubber run over a list you already own.

The blacklist monitors are the part that has no equivalent elsewhere in this category. Most verification services grade other people's addresses. ValidEmail.co also watches yours. A monitor is a persistent object with a UUID against a domain or an outbound mail server IP, and every read returns a map keyed by blocklist name with a boolean per list. That gives an agent something to poll on a schedule and something concrete to escalate on, which is the difference between a reputation you assume is fine and one you can actually observe. FlowRunner treats a red monitor as an automation exception: the flow does not fail, it routes the question to whoever owns the consequence.

Without FlowRunner

Reputation checked after the fact A listing gets noticed when open rates drop, days later

Bad addresses enter at the door Fake and disposable sign-ups land in the CRM and are cleaned much later, if at all

No standing record of the watch Nobody can say when a sending IP was last clean or which blocklist flagged it

With FlowRunner

Reputation is a monitored object The sending domain and outbound IP carry a monitor with a per-blocklist result map

Verdict at capture Each address gets a deliverable, undeliverable, risky or unknown verdict before the record is created

Listings raise a decision A new listing surfaces as a question about today's sends, not as a line in a log

Use Case Scenarios

Verdict at the sign-up form

A trial sign-up posts an address. Before any record is created, the agent calls Validate Email and reads the verdict along with the quality score and the flags. Undeliverable addresses are rejected at the form with a message asking for a correction. Disposable domains are rejected outright. Role addresses such as info@ and sales@ are accepted but written into HubSpot with the owner field left empty and a task raised, because a role address is a real inbox with no identifiable person behind it and routing it to a rep as a named lead is a small lie the CRM will carry forever. Deliverable addresses flow straight through.

Standing watch on the sending estate

When a new sending domain or outbound mail server is provisioned, a flow calls Create Blacklist Monitor and stores the returned UUID alongside the infrastructure record in Notion. A scheduled flow then walks List Blacklist Monitors and reads each one, comparing the current result map against the last stored map. Nothing happens while every value stays false. The moment a blocklist flips to true, the agent opens the incident and pulls in the campaign calendar so the person deciding has the exposure in front of them rather than just the alert.

Retiring infrastructure without losing the record

A sending IP is decommissioned. The agent calls Delete Blacklist Monitor to stop checking it, but only after writing the monitor's final result map and its full history into the infrastructure record. The deletion is irreversible and the API returns no body, so the connector confirms the deleted UUID and the agent files that confirmation. When someone asks in six months whether that IP was ever listed, the answer exists outside the vendor.

Human-in-Loop Highlight

The gate is on halting sends. When a monitor flips to listed, both available responses cost something real. Holding the day's campaigns means a scheduled revenue send does not go out and cannot simply be rerun tomorrow without the offer being stale. Letting them run means pushing more volume through a domain a blocklist has already flagged, which deepens the listing and drags the delisting request out. No score decides that, and the agent does not pretend otherwise. It posts the specifics to Slack: "Blacklist monitor on mail.example.com flipped to listed on two blocklists this morning. Four campaigns are scheduled in the next 18 hours, totalling 94,000 recipients. Hold all four, hold the two promotional sends and release the two transactional ones, or release everything and file the delisting request now?" A person answers, the flow resumes on that answer, and the decision is recorded next to the monitor that raised it. This is the digital andon cord in its plainest form: the agent stopped the line because the next step was not its call to make.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via Slack

Human decides

Agent resumes with decision

Agent Capabilities

5 actions

Email Validation

Validate Email Verifies a single address in real time and returns a deliverability verdict, a machine-readable reason, a quality score, the parsed username and domain, the resolved MX record, and flags for free mailbox providers, disposable domains, catch-all domains and generic role addresses. Used at the point of capture on sign-up, lead and checkout forms, where one synchronous answer decides whether the submission is accepted.

Blacklist Monitoring

Create Blacklist Monitor Registers a domain or IP address for ongoing blacklist monitoring and returns the new monitor UUID along with the first check. Used when a sending domain or outbound mail server is provisioned, so the reputation watch starts on day one rather than after the first incident.
List Blacklist Monitors Retrieves every monitor configured on the account with its UUID, monitored value, status and timestamps. Used as the enumeration step in a scheduled sweep across the whole sending estate.
Get Blacklist Monitor Retrieves one monitor by UUID together with its latest results, keyed by blocklist name with a boolean per list. Used to confirm exactly which blocklists are involved before an incident is opened.
Delete Blacklist Monitor Permanently removes a monitor so the domain or IP is no longer checked. Used when infrastructure is decommissioned. The check stops silently once it is gone, so the monitor history belongs in the system of record before this runs.

Frequently Asked Questions

What can FlowRunner do with ValidEmail?

FlowRunner agents can run Validate Email, List Blacklist Monitors, and Create Blacklist Monitor in ValidEmail, plus 2 more actions.

Does connecting ValidEmail to FlowRunner require OAuth?

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

Can ValidEmail trigger a FlowRunner workflow automatically?

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

Start building with ValidEmail

$100 in credits. No card required. Connect in minutes.

Start Building Free Talk to us