Product
Check an address before you send to it, through the same compatible APIs you already use. The distinguishing feature is not the check itself - it is that validating an address means handing it to a processor, and Omnivery's is EU-incorporated with all processing in the EU.
Last reviewed July 2026
Email validation checks an address before you send to it, so that an obviously undeliverable address never becomes a hard bounce against your sending reputation. It is most valuable at the point of capture - a signup form, a checkout, an imported list - because that is where a typo or a deliberately fake address enters your data.
Validation is oversold across this category, so the limits matter. No validation service can tell you with certainty that a mailbox exists and will accept mail; receivers deliberately obscure that, and many accept everything at the SMTP conversation and decide afterwards. What validation reliably catches is syntax errors, domains that do not resolve or accept mail, disposable and throwaway domains, and role addresses. Treat the result as a strong signal, not a guarantee.
Validation also does not tell you whether an address belongs to a person who wants your email. That is a different question, and it is the one Bot Detection answers - by classifying the engagement after delivery rather than the address before it. A perfectly valid address can generate entirely automated opens and clicks.
Validation is exposed through the compatible APIs rather than through an Omnivery-specific endpoint, so an existing client library works. All four API dialects implement it.
That second point catches people out during a migration, because POST /v3/mail/send accepts either credential scope. Sending therefore works on an account-level key while validation returns an authentication error on the same key, which reads like a broken endpoint rather than a credential rule.
GET /address/private/validate on base URL https://mg-api.omnivery.net/v3, with the address passed as an address query parameter and HTTP basic authentication using the username api and the key as the password. A companion GET /address/private/parse handles address parsing. Validation is one of roughly 33 documented endpoints in this dialect, which is why it is the one to choose for a new integration.
POST /recipient-validation/single/{address} on base URL https://sp-api.omnivery.net/api/v1. The address travels in the path rather than a request body. This dialect covers roughly 21 endpoints, so recipient validation sits alongside transmissions, sending domains, webhooks, API keys and suppression lists.
POST /validations/email on base URL https://sg-api.omnivery.net/v3, with Bearer token authentication and a JSON body containing a single email field. The SendGrid shim implements only send and validation, so it suits an existing SendGrid integration but is a thin base to build a new one on.
GET /{domain}/validate on base URL https://zap-api.omnivery.net, authenticating with an ov-token header rather than a bearer token or basic auth. This is the lightweight dialect the official Make.com app is built on, and it is the right one when the caller is a workflow tool rather than an application you control.
The developer page covers the rest of the migration sequence. Endpoints as published in the Omnivery API reference at omnivery.com/docs, August 2026 - check it against the current reference before relying on any single path.
Most providers do not name their validation vendor at all. To validate an address you have to send that address to whoever performs the check. An email address is personal data, so enabling validation adds a processor to your chain and a row to your own sub-processor disclosure.
On Omnivery, validation is performed by Bouncer Sp. z o.o., a Polish company, which processes in EU-based Amazon Web Services infrastructure in the Frankfurt region. Amazon Web Services is therefore a sub-processor of Bouncer. Both appear on Omnivery's published sub-processor list with their addresses, purposes and processing locations, so you can forward that list to a reviewer rather than assembling it yourself.
The core email service has no sub-processors at all - delivery runs on infrastructure Omnivery owns, with no hyperscaler in the path. Validation and SMS are the two features that introduce one, and both are choices you make rather than defaults you inherit. See the GDPR compliant email API page.
White-glove deliverability
Validation removes addresses that were never going to work. It does not tell you whether the rest of your sending is healthy, and a clean list is not the same as a good sender reputation. Everywhere else that expertise is a separate invoice - a consulting tier, a premium add-on, a business unit that bills you when sending goes wrong. We do not have a deliverability business unit, because deliverability is the business.
At a glance
Questions
Yes, and through the compatible APIs rather than a proprietary endpoint. All four dialects implement it: GET /address/private/validate on the Mailgun-compatible https://mg-api.omnivery.net/v3, POST /recipient-validation/single/{address} on the SparkPost-compatible https://sp-api.omnivery.net/api/v1, POST /validations/email on the SendGrid-compatible https://sg-api.omnivery.net/v3, and GET /{domain}/validate on the Automations API at https://zap-api.omnivery.net. Validation is an optional feature that has to be enabled per sending domain before any of them will answer.
Because validation accepts only domain-level API credentials, in every dialect. An account-level key is rejected. This is confusing in practice because POST /v3/mail/send accepts either credential scope, so the same key sends successfully and fails on validation. Check also that validation is enabled in the domain settings, since the endpoint does not respond until it is.
Bouncer Sp. z o.o., a Polish company registered at ul. Cypriana Kamila Norwida 24/1, 50-374 Wrocław, which processes in EU-based Amazon Web Services infrastructure in the Frankfurt region. Amazon Web Services is a sub-processor of Bouncer. Both are named on Omnivery's published sub-processor list at /legal/gdpr with their addresses, purposes and processing locations.
It adds a processor to your chain, because an email address is personal data and validating it requires transmitting it to whoever performs the check. That is true of every validation service, and it is why Omnivery publishes the vendor rather than describing validation as an internal feature. The vendor is EU-incorporated and processes in the EU, so for an EU controller there is no third-country transfer to legitimize for this feature. If you do not enable validation, no address of yours reaches a validation vendor at all.
No, and no provider can. Many receivers accept every address at the SMTP conversation and decide afterwards, and some deliberately obscure whether a mailbox exists in order to frustrate address harvesting. Validation reliably catches syntax errors, domains that do not resolve or accept mail, disposable and throwaway domains, and role addresses. Treat the verdict as a strong signal rather than a guarantee.
No, and they answer different questions. Validation assesses an address before you send, asking whether mail can be delivered to it. Bot Detection assesses engagement after delivery, asking whether the opens and clicks came from a person. A valid, deliverable address can produce entirely automated engagement - a security gateway following every link, for example. See the Bot Detection API for that.
Validation is part of the platform rather than an add-on priced per thousand checks. Talk to us about enabling it on your domain.