Transactional email — password resets, receipts, system alerts — is invisible when it works and a support-ticket generator when it doesn't. MetaReach's email API is built for the specific sending patterns SaaS platforms need: fast, reliable, and separated from your platform's marketing email to protect deliverability.
Core Use Cases
Sign-up verification, password resets and magic-link logins. The user is waiting on the screen, so these go out the moment the event fires.
Payment confirmations, renewal receipts, GST invoices and failed-payment notices that customers and their finance teams need on record.
Usage-limit warnings, new-login security alerts, integration failures and scheduled-maintenance notices.
Welcome emails, team invitations, setup confirmations and "your export is ready" notices tied to what the user just did.
MetaReach's transactional email API delivers password resets, receipts, system alerts, and onboarding emails on separate transactional sending infrastructure, isolated from marketing-email reputation risk, triggered via REST API from your application events.
Why Separate
A SaaS platform typically sends two very different kinds of email off the same account — product marketing and newsletters to the same users who also need password resets, billing receipts, and account-security alerts. If a marketing send to that user base gets flagged as spam, it can drag down inbox placement for time-sensitive, event-triggered emails going out to your entire multi-tenant customer base at the same time. MetaReach's transactional email API runs on separate transactional sending infrastructure, keeping these application-triggered sends isolated from marketing-email reputation risk.
Event Map
Most SaaS products need the same ten or so transactional emails. Mapping each one to the event that fires it, and to how quickly it must arrive, tells your engineering team what to build first and what to monitor most closely.
| Application event | Email sent | How urgent | What to get right |
|---|---|---|---|
| User signs up | Email verification | Immediate: the user is waiting | Single-use link with a short expiry, and a clear resend option in the app |
| Forgot password | Password reset link | Immediate: the user is locked out | Show the same response whether or not the email exists, so attackers can't confirm accounts |
| Login from a new device | Security alert | Immediate | Device, location and time, plus a link to secure the account |
| Teammate invited | Workspace invitation | Within minutes | Name the inviter and the workspace so it isn't mistaken for spam |
| Payment succeeds | Receipt or GST invoice | Within minutes | Invoice number, GSTIN and amount; send to the billing contact, not only the admin |
| Payment fails | Failed-payment notice | Within minutes | A direct link to update the card, and the date access will be paused |
| Usage reaches 80% / 100% of plan | Limit warning | Within the hour | Fire once per threshold per billing cycle, not on every API call |
| Trial ends in 3 days | Trial-ending reminder | Scheduled | Keep it factual; heavy upsell content turns it into a marketing email |
| Export or report finishes | "Your file is ready" | Within minutes | Link to an authenticated download rather than attaching the file |
Sending Identity
Inbox providers judge your email partly by the domain it comes from. A SaaS platform protects its transactional reputation by giving each type of mail its own subdomain, so a poorly received newsletter never shares a reputation with a password reset.
notify.yourapp.com for
transactional email and news.yourapp.com for product updates and newsletters.
Each subdomain builds its own sending history.no-reply
mailbox nobody checks.For the full checklist covering authentication, PTR records, TLS and IP warm-up, see our email deliverability guide.
Engineering Checklist
The email API call itself is a few lines of code. Most production problems come from the code around it. These are the practices our team reviews with SaaS engineering teams during onboarding.
Put the send on a background job queue when the event fires. If the email call is made inside the user's HTTP request, a slow response holds up the sign-up or checkout page, and an error can roll back an action that actually succeeded.
Retry timeouts and server errors (5xx) with increasing delays between attempts. Do not retry validation errors (4xx) such as a malformed address; log them and fix the cause, or the job will fail the same way every time.
Store a unique key for each event, such as invoice_8841_receipt, and check it before
sending. Without this, a retried job or a duplicate payment webhook sends the customer two
receipts, which leads to support tickets asking whether they were charged twice.
Process bounce and spam-complaint notifications as they arrive. Stop sending to addresses that hard-bounce, and flag the user record so your app can prompt them to update their email the next time they log in. Repeatedly sending to dead addresses damages the reputation your password resets depend on.
Save the message ID returned by the API alongside the user and the event. When a customer says "I never got the reset email," support can look up exactly what was sent, when, and whether it was delivered, bounced or deferred.
Never email passwords, full card numbers or API keys. Reset and login links should be single-use and expire quickly. For documents containing personal or financial data, email a link to an authenticated page rather than attaching the file.
Common Mistakes
An email is transactional because of what it does, not which system sends it. A message triggered by the user's own action, which they need in order to use the product, is transactional. Anything designed mainly to promote is marketing, even when an event triggers it. Three patterns cause the most trouble:
When you also need campaign email to the same user base, run it through MetaReach's email marketing services on its own subdomain, so the two streams never share a reputation.
Go Further
Transactional email is one piece of a SaaS platform's communication needs — these resources round out the rest.
How SaaS and ERP platforms connect OTP, SMS, WhatsApp and email to their backend.
View Integration OverviewSee how SaaS platforms and ERP providers use this infrastructure.
View Use CasesMetaReach's main email marketing/campaign platform.
View Email Marketing ServicesMore detail on MetaReach's transactional email infrastructure.
View Transactional Email ServiceIn-app alerts and updates delivered via WhatsApp.
Explore WhatsApp NotificationsVoice-based support routing and escalation.
Explore IVR for Customer SupportResell this infrastructure under your own brand.
Explore White-Label OptionsNeed the rest of the SaaS & ERP communication stack? See the SaaS & ERP Messaging Solutions pillar for OTP, WhatsApp, SMS, IVR, and API integration in one place.
Common Questions
Yes — transactional email uses separate transactional sending infrastructure, isolated from promotional/marketing email sends, to protect deliverability.
Yes — REST API integration for triggering transactional emails from your application events.
Transactional email is prioritized for fast delivery given the time-sensitive nature of use cases like password resets.
Yes — see our main Email Marketing Services page for marketing/campaign email, and our Transactional Email Service page for more transactional-specific detail.
Genuinely transactional emails, such as password resets, receipts and security alerts, are messages the user needs in order to use the product, so they are normally sent without an unsubscribe link. Gmail and Yahoo's one-click unsubscribe requirement applies to marketing and subscribed mail. If an email is mostly promotional, treat it as marketing and include one-click unsubscribe.
Use the same brand domain but separate subdomains, for example notify.yourapp.com for transactional mail and news.yourapp.com for newsletters. Each subdomain builds its own sending reputation, so a newsletter that draws spam complaints does not affect delivery of password resets.
Stop sending to an address that hard-bounces, record the bounce against the user, and ask the user to update their email address the next time they log in. Continuing to send to addresses that bounce harms your sending reputation.
From startups to enterprises — brands that grow with MetaReach
