Omnivery

Omnivery is a transactional email delivery platform focused on deliverability. Agents send mail from a verified domain, parse and validate addresses, manage suppressions, detect bot traffic, and configure domains and webhooks.

Verified 12 actions API key available

Platform Documentation Capability data verified 2026-08-19

A recipient list arrives from an event export or a partner campaign

Parse Addresses splits the pasted list into structured records and reports what it could not read

Validate Address returns a verdict and the reason behind it for each address

Agent separates real verdicts from the reasons that describe an unreachable mail server rather than a bad address

Send Message delivers to the addresses that passed, from the verified sending domain

The list owner receives the unparseable rows and the retry set as named groups

The list owner confirms which addresses get suppressed, because this connector has no operation that takes them off

What This Integration Enables

Omnivery is for senders who have stopped trusting their own engagement numbers. The platform speaks several vendor compatible dialects so an existing integration can be repointed without rewriting it, but the operations that do not exist elsewhere are the interesting ones: address parsing that hands back what it could not read, validation that names the check behind each verdict, and bot detection that takes up to five hundred opens or clicks per request and tells you which of them a machine generated. That is a deliverability platform whose product is doubt, applied usefully.

FlowRunner agents use that doubt as workflow structure. They parse before they validate, validate before they send, separate the verdict reasons that describe an unreachable mail server from the ones that describe a bad address, and send from a verified domain with tracking and per message overrides. Two facts shape every workflow built here. Validation is powered by a third party, so an address checked is an address that has left the platform, and suppression on this connector is a one way door. Both are reasons FlowRunner's human-in-the-loop design belongs in the flow rather than in a runbook nobody reads.

Without FlowRunner

Engagement taken at face value Opens and clicks are counted without asking which of them came from a security scanner

Lists cleaned by eye A pasted recipient list gets split on commas and the malformed rows are found by the bounce report

Retryable failures treated as verdicts A mail server that timed out gets recorded as a dead address and the customer stops receiving mail

With FlowRunner

Engagement checked before it is believed Interactions go through bot detection first, so a reported click has been examined rather than assumed

Lists parsed and validated as a step Structure, then verdict, then reason, with the unreadable rows handed back rather than dropped

Failures separated from facts Reasons that describe an unreachable server are retried; only real verdicts reach a suppression decision

Use Case Scenarios

An imported list that gets cleaned before it costs anything

A list arrives as a sheet in Google Sheets or an export from an event platform. The agent calls Parse Addresses to turn the raw string into structured records with a local part, a domain, and anything it could not read reported separately. Each survivor goes through Validate Address, which returns deliverable, undeliverable, risky, or unknown together with the reason. The agent groups the results by reason rather than by verdict, because four of the reasons describe a failure to reach the mail server rather than a fact about the address. Those go into a retry set. The clean addresses reach Send Message from the verified domain, and the unreadable rows go back to the list owner with the row numbers attached.
Engagement that has been checked, not just counted

Opens and clicks accumulate through the domain's tracking. On a schedule, the agent batches up to five hundred interactions, each carrying at least a source address, a user agent, and an event identifier, and submits them with Detect Bot Interactions. Results arrive asynchronously at the webhook the call names, and Get Bot Detection Result reads any single one back by request identifier. A 404 there means either not yet processed or already expired, so the agent treats it as retryable rather than as a negative answer. The verified engagement, not the raw counts, is what lands in the weekly report and what feeds any downstream scoring in HubSpot.
A receiving endpoint that stays subscribed

Omnivery is strict about how a webhook endpoint answers, and several response codes get an endpoint switched off rather than retried. So the agent builds the receiver against a sample from Get Webhook Sample before subscribing anything, registers with Subscribe Webhook, and reads back the answer carefully, because a payment sounding refusal there means the endpoint itself failed the vendor's check rather than that anything is owed. It also builds the receiver around the timestamps in the payload rather than around arrival order, since an open can arrive ahead of the delivery it belongs to. When an endpoint is retired, Unsubscribe Webhook removes the type and every URL registered under it, and the agent posts the change to Slack so the team knows which events stopped.

Human-in-Loop Highlight

Suppress Address has no counterpart on this connector. There is a call that stops delivery to an address on a domain and no call that starts it again, so once an agent suppresses someone, only a person working in Omnivery's own interface can undo it. That asymmetry is what makes the end of every list hygiene run a decision rather than a write. The agent assembles the case: the addresses whose validation verdict was a genuine fact about the mailbox, separated from the ones whose reason was an unreachable server, and the openers whose interactions came back flagged by bot detection, separated from the ones whose result is still pending. Then it asks the marketing owner: "Fourteen addresses returned undeliverable with a mailbox level reason and are safe to suppress. Nine returned a server reachability failure and I would retry those instead. Three are on your paying customer list. Confirm the suppression set." Nothing gets written to a one way list on an agent's judgment alone.

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

12 actions

Sending

Send Message Sends an email through a verified sending domain, with stored templates and variables, per message tracking overrides, custom headers, custom variables carried through to webhooks, attachments, and a per call webhook override. A test mode send delivers nothing, which makes a genuine dry run possible.

Address Quality

Parse Addresses Splits a string of addresses into structured records with the local part, the domain, and the address itself, and reports anything it could not read separately. Used to clean an imported or pasted list before any of it is trusted.
Validate Address Validates one address and returns the verdict, the reason behind it, the role, free provider, disposable, and accept all flags, and a typo suggestion where one applies. Validation runs through a third party and has to be enabled on the domain first, so it is a deliberate step rather than a default.
Suppress Address Adds an address to a domain's suppression list with the reason recorded alongside it. Suppression is per domain, and this connector offers no way to reverse it, which is why it sits behind the human gate above.

Bot Detection

Detect Bot Interactions Submits up to five hundred open or click interactions for bot detection and returns a batch identifier. Each event needs at least a source address, a user agent, and an event identifier, and more context improves the result.
Get Bot Detection Result Reads one bot detection result by its request identifier, returning the verdict together with the interaction it was made from. A not found answer means either still processing or already expired, so workflows retry rather than concluding.

Domains

List Domains Returns the sending domains the key can reach with their state and data location. Also the quickest way to tell whether a key is account level or scoped to a single domain.
Get Domain Returns one sending domain in detail, optionally with the DNS records it needs. The read to run when a send is refused for a From address that looks correct.

Webhooks

Subscribe Webhook Registers a webhook endpoint on a domain so message events are posted to it, with up to three URLs per type. A click or open subscription only fires when the matching tracking is enabled on the domain.
Unsubscribe Webhook Removes a webhook type from a domain. Every URL registered under that type goes with it, because the type rather than the URL is what is addressed.
Get Webhook Sample Returns a sample payload for one webhook type, which is how a receiving flow gets built and tested without waiting for a real event.

Account

Test Connection Confirms the API key is accepted and reports what it is bound to, including its role. A sending role key can post messages but cannot manage the account, so this is the first call to run when management fails while sending works.

Frequently Asked Questions

What can FlowRunner do with Omnivery?

FlowRunner agents can run Send Message, Parse Addresses, and Validate Address in Omnivery, plus 9 more actions.

Does connecting Omnivery to FlowRunner require OAuth?

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

Can Omnivery trigger a FlowRunner workflow automatically?

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

Start building with Omnivery

Free plan, no card required. Connect in minutes.

Start Building Free Talk to us