Travel & hospitality
A booking confirmation is not a notification. It is the record the traveler presents at a desk, the reference they need to change a flight, and often the only proof the transaction happened. A gate change at 04:00 has to arrive at 04:00. Omnivery is transactional email infrastructure for travel businesses where a delivery failure is an operational incident rather than a metric.
Updated: July 2026
Travel email has a set of constraints that most transactional email does not, and they tend to surface at the worst possible time.
A retail receipt that arrives twenty minutes late is a minor annoyance. A schedule change that arrives twenty minutes late can mean a missed connection. Travel is one of the few categories where delivery latency has a direct operational consequence, and where the message often has to reach someone who is already in transit and reading on a phone.
A status page will not tell you any of this; a deliverability analyst will. Omnivery includes senior deliverability analysts rather than invoicing them as a tier, and they monitor sending around the clock and make contact proactively when patterns look wrong.
Travelers unsubscribe from promotional email constantly, and they still need their itinerary. On many platforms an unsubscribe suppresses everything, including the booking confirmation.
Omnivery treats transactional messages as bypassing unsubscribe and complaint suppressions, so a confirmation or a schedule change still reaches someone who opted out of marketing. Bounce and block suppressions still apply. Transactional mode is enabled per domain by the Omnivery team rather than self-serve, because it changes suppression behavior.
A travel business sends to whatever mailbox provider the traveler happens to use, which means the regional and national providers a global platform treats as tail traffic. Delivering well into them is a different discipline from delivering well into the large US providers.
Omnivery grew out of Mailkit, founded in the Czech Republic in 2006, and maintains provider relationships reaching niche markets. It is a member of M3AAWG, of the Certified Senders Alliance - the European sender accreditation scheme, which carries particular weight with German and wider European receivers - and of Signal Spam in France.
Bookings contain names, travel dates, routes and sometimes passport or payment references. For an EU business that is consumer personal data with a clear cross-border dimension.
Omnivery is operated by a Czech entity, runs exclusively on infrastructure it owns with no AWS, Azure or Google Cloud in the delivery path, never stores message body content, and caps delivery metadata at 30 days. There are no US sub-processors in the core email service; US-incorporated vendors apply only to optional, customer-selectable features. Data residency is a customer choice between EU and US, on owned infrastructure either way.
Travel volume is not smooth, and the worst spikes are the ones you did not schedule: weather, a strike, or a cancellation cascade produces a burst of rebooking messages exactly when they matter most.
Omnivery sending domains carry a rate limit that increases automatically by 20% at 75% utilization. For known peaks, raise the ceiling with the team in advance. For disruption scenarios, agree the likely shape of the spike before one happens.
Kiwi.com is an online travel agency operating at high volume, and it was sending through both SendGrid and Mailgun. It moved to Omnivery through its Bloomreach Engage integration.
The order was the opposite of how a travel business usually evaluates an email provider. Marketing went first: Kiwi.com moved marketing email off Mailgun, and the performance it saw there is what led to the second stage, running Omnivery against SendGrid in a split environment on transactional mail. Kiwi.com sends both streams with Omnivery today - the campaign and the booking confirmation under one provider, on separate DKIM keys and separate IP pools so the reputations stay apart.
Complete switch from SendGrid and Mailgun, using Omnivery's native compatibility with both APIs rather than a development project.
Recorded after the migration, on the same programs and the same audience.
Sent through Bloomreach Engage, for which Omnivery is a native provider and emits two dedicated webhook formats.
The migration took under an hour rather than a quarter for the same reason Omnivery can act as a second sending path: it implements the SendGrid v3 and Mailgun v3 request formats natively, so an existing integration keeps working once the endpoint and key change. The full write-up is available as a case study.
Booking confirmations, e-tickets, itinerary changes and refund confirmations, where the message is the record of the transaction rather than a notification about it.
Schedule changes, gate and platform updates, disruption rebooking and check-in reminders, with volume that spikes exactly when delivery matters most.
Reservation confirmations, pre-arrival details, access codes and folio receipts, often sent to a guest already traveling and reading on a phone.
Where the email carries the entry token and a delivery failure becomes a queue at the door rather than a support ticket.
Passenger data under GDPR, delivery into regional and national mailbox providers, and EU or US data residency as a customer choice on owned infrastructure.
Native integrations for Bloomreach Engage, Targito and Meiro, an official Mautic plugin, and compatible SendGrid, Mailgun and SparkPost APIs for anything else.
Yes, provided it is sent on a domain configured as transactional. Omnivery treats transactional messages as bypassing unsubscribe and complaint suppressions, on the basis that an itinerary or a schedule change is part of delivering the service rather than a marketing communication. Bounce and block suppressions still apply, because those addresses genuinely cannot or must not receive mail.
Transactional mode is enabled per domain by the Omnivery team rather than being self-serve, precisely because it changes suppression behavior. Separating marketing and transactional streams onto different sending domains is the usual pattern.
Kiwi.com completed a switch from both SendGrid and Mailgun in 45 minutes, and recorded a 17% improvement in unique click rate against SendGrid over the following twelve months.
That is possible because Omnivery natively implements the SendGrid v3, Mailgun v3 and SparkPost v1 request formats, so an existing client library keeps working once the base URL and API key change. One-click migration also transfers domain settings, webhooks, suppressions, allowlists and templates. The one lead time to plan for is vetting: every sending domain is vetted before it can send, normally within one to three working days.
Each sending domain carries a rate limit that increases automatically by 20% when it reaches 75% utilization, which handles ordinary growth without intervention. Disruption spikes are different in kind, so it is worth discussing the expected shape with the deliverability team in advance and having the ceiling raised before the season rather than during an incident.
Senior analysts are included in the service and monitor sending around the clock, contacting customers proactively when patterns look wrong.
All Omnivery operations are performed by the Czech entity, including the US data centers. The Austin office is a sales function and operates no infrastructure. Data residency is offered as a customer choice between EU and US, on infrastructure Omnivery owns in both cases, so choosing US residency changes where the machines are without changing who the processor is or which legal system governs it.
Omnivery never stores message body content, and delivery metadata is capped at 30 days. There are no US sub-processors in the core email service; US-incorporated vendors apply only to optional, customer-selectable features. The published sub-processor list is here, and the regulatory reasoning is on the GDPR compliant email API page.
Yes, through email journaling, which sends exact copies of outgoing messages to an archive address, enabled with a single domain setting rather than BCC rules in application code.
Omnivery does not retain message content itself: delivery metadata is kept for at most 30 days and then reduced to summary volume counts. If you need the message body retained for a dispute or a regulator, journaling is the mechanism.
Bloomreach Engage is a native integration, and Omnivery emits two dedicated Bloomreach webhook formats so engagement events flow back without a translation layer. This is the path Kiwi.com uses. Meiro also has a native integration, and Mautic is covered by an official open-source transport plugin.
Any other platform can connect through the compatible SendGrid, Mailgun or SparkPost APIs, through the Automations API and official Make.com app, or through the SMTP relay, which carries full API parity.
Yes, and for time-critical travel messaging that is often the more sensible first step. Because Omnivery accepts the same requests as SendGrid, Mailgun or SparkPost and can emit webhooks in those same formats, a second sending path does not require a second integration on either the outbound or the inbound side.
Two practical points: the standby domain has to be vetted in advance, so it cannot be created during an incident, and it is worth sending a steady share of real traffic through it so the route stays warm and its reputation is established. See the developers page.
If a delivery failure in your booking flow becomes an operational incident rather than a metric, it is worth having the deliverability conversation before the next peak. Domain vetting takes one to three working days, so there is a lead time either way.