--- title: Email Engineering for AI-Booked Travel Confirmations description: "React-based email templates, multi-language support, and dynamic content for AI-booked trips. Here is how we build transactional travel emails." canonical: https://nowah.xyz/blog/email-engineering-ai-booked-travel lastModified: "2026-08-07T03:47:42.575Z" --- # Email Engineering for AI-Booked Travel Confirmations React-based email templates, multi-language support, and dynamic content for AI-booked trips. Here is how we build transactional travel emails. Travel confirmation emails are one of those things that seem simple until you actually build them. Send an email with the flight details, right? How hard can it be? Harder than you think. Especially when the booking data comes from a conversation with an AI agent instead of a structured form. ## Why travel emails are different ![Illustration for this section](https://pics.nowah.xyz/website-media/engineering-026-img-1.webp) Most transactional emails follow a template with a few variable fields. Your order confirmation from an online store has a product name, a price, and a shipping address. Plug in the values, send it, done. Travel confirmations are a different animal. A single booking might include a multi-leg flight with different airlines on each segment, a hotel with specific check-in instructions, and an itinerary that spans two weeks across three countries. The email has to render all of that clearly on every email client from Apple Mail to Outlook 2016 to Gmail on a Pixel phone. When the booking comes from an AI agent conversation, the data is even more variable than form-based bookings. A user might book a one-way flight in one conversation and a complex [multi-city](/blog/multi-city-flight-booking-ai-agents) itinerary with hotels in another. The email template has to handle both gracefully without looking broken when half the sections are empty. ## React-based email templates We build our [email templates](/blog/react-email-templates) as React components. This gives us the same component model we use in the rest of our frontend, which means our engineers do not need to context-switch into a completely different paradigm when working on emails. The component architecture works well for travel emails specifically because we can compose them from smaller pieces. A flight segment component renders one leg of a journey. A hotel card component renders one property. The confirmation email assembles these pieces based on what was actually booked, so a simple one-way flight gets a clean single-card email while a multi-city trip with hotels gets a richer layout. The big challenge with React-based emails is that email clients are stuck in 2005. CSS support is wildly inconsistent. Flexbox does not work. Grid does not work. You end up writing table-based layouts with inline styles, which feels absurd when you are used to modern web development. Our component library abstracts most of this pain away, but it was not free to build. ## Dynamic content from AI-booked trips ![Supporting diagram](https://pics.nowah.xyz/website-media/engineering-026-img-2.webp) When a user books through a traditional form, the data structure is predictable. You know exactly which fields will be present because the form enforced them. When a user books through our AI agent, the data is richer and more variable. The AI might have extracted a seat preference, a meal request, or a note about [connecting flights](/blog/direct-vs-connecting-flights-ai-decides) that does not fit neatly into a standard template field. We solve this with a data extraction layer that sits between the booking confirmation and the email renderer. It pulls structured data from the booking record, but it also pulls context from the conversation that led to the booking. If the user mentioned they are celebrating an anniversary, we can include a small note in the confirmation. If the AI recommended a specific terminal for their connection, that goes in too. This is one of those places where AI-native products can be genuinely better than traditional ones. The email is not just a receipt. It is a personalized travel brief. ## Multi-language support Our users book from everywhere. The confirmation email needs to arrive in the language they used during their conversation with the AI agent. We store language preference at the user level and use it to select the right template strings at render time. Travel emails are tricky to localize because they mix fixed template text ("Your booking is confirmed") with dynamic content that should not be translated (airline names, airport codes, hotel addresses). Getting this right requires careful separation of translatable strings from pass-through data. We support over 80 languages for the AI agent conversation, and our email templates cover the most common ones with fallback to English for the rest. It is not perfect, but it means a user in Tokyo gets their confirmation in Japanese and a user in Sao Paulo gets theirs in Portuguese. ## Getting past spam filters Travel confirmation emails contain a lot of spam-filter triggers. Dollar amounts. Urgency language ("Your flight departs in 3 days"). Links to external sites. Attachment-like content. All things that spam filters love to flag. We invest in email deliverability because a travel confirmation that lands in spam is worse than no email at all. The user thinks the booking failed. They panic. They contact support. It is a terrible experience. Our approach includes proper authentication (SPF, DKIM, DMARC), careful content structure, consistent sending patterns, and monitoring deliverability rates per email provider. We track open rates not for marketing purposes but as a signal that the email actually reached the inbox. For a travel platform, email deliverability is not a nice-to-have. It is part of the booking infrastructure. --- Nowah is an AI travel agent that searches and books real flights and hotels through conversation — no filters, no thirty open tabs. [Plan your next trip](https://app.nowah.xyz).