Skip to main content

Transactional email overview

Transactional emails are one-to-one emails triggered by something happening: an order confirmation, a password reset, a double opt-in confirmation. They are not marketing. SmartMailing treats them as a separate system with its own sending stream, its own rules, and its own pages in the dashboard.

You'll find everything under Transactional in the dashboard, split into four tabs:

  • Emails: the default lifecycle emails (double opt-in confirmation, welcome, unsubscribe receipt) that the platform sends automatically. See Default transactional emails.
  • Custom events: your own transactional emails, like an order confirmation, built from a template and sent by an event key. See Custom events.
  • Triggers: no-code webhook URLs that outside tools (Stripe, Shopify, Zapier) can call to fire an event. See Triggers and the send log.
  • API keys: per-brand keys your code uses to call the send API. See Send with the API.

A separate sending stream​

Every brand sends transactional email on its own dedicated stream, on a separate sending subdomain of your verified domain, with a reputation kept apart from your marketing stream. Emails go out from your own domain, never from ours, with a from address like Your Brand <notifications@your-transactional-subdomain>.

The separation matters in practice:

  • A marketing unsubscribe never blocks a transactional email. Someone who opted out of your newsletter still gets their receipt.
  • Only a hard bounce or a spam complaint suppresses a recipient on the transactional stream. If you try to send to a suppressed address, the send is skipped and logged as recipient_suppressed.
  • A deliverability problem on one stream does not drag down the other.

No open or click tracking, by design​

SmartMailing does not track opens or clicks on transactional email. No tracking pixel is inserted and links are not rewritten. That is deliberate: receipts and password resets are private, and untouched links in security-sensitive emails are better for trust and deliverability.

Delivery, bounces, and complaints are still recorded, and every API or trigger send appears in the send log with its result.

What you need before sending​

  • A plan that includes transactional sending. Sending through the API or triggers requires the Growth plan or higher. If your plan does not include it, sends are rejected with transactional_not_enabled. You can still build events and preview renders before upgrading.
  • A verified transactional stream. Your brand's transactional sending domain must be set up and verified. Until it is, sends are rejected with transactional_stream_not_ready.

The default lifecycle emails on the Emails tab (double opt-in confirmation, welcome, unsubscribe receipt) are part of the platform's subscribe and unsubscribe flows and are sent automatically, so you do not call an API for those.

Two ways to send a custom event​

Once an event exists, there are two ways to fire it:

  1. The API, if you have a developer: your app calls POST /api/v1/transactional/send with an API key.
  2. A trigger, if you don't: you get a URL to paste into an outside tool, and map its payload to your event with clicks.

Both paths render the same template with the same data rules, share the same rate limits, and land in the same send log.