Event-triggered email: a practical guide for founders

Most first email programs are one of two things: a newsletter someone remembers to send, or a welcome sequence that fires on a fixed schedule after signup. Both are fine starting points. Neither reacts to anything the user actually does. Event-triggered email closes that gap: it starts a flow the moment something happens in your product, not some number of days after signup regardless of what's happened since.

The difference that matters

A date-based drip asks "how long has it been since X?" An event-triggered flow asks "did X just happen?" That sounds like a small distinction, but it changes what the email can say.

A day-three onboarding nudge sent on a timer can't know whether the user already finished onboarding on day one. It either fires anyway and looks oblivious, or you bolt on a manual check to suppress it. An event-triggered version doesn't have this problem: it only starts because the qualifying action happened, so there's nothing to suppress. "Finished onboarding" and "send the onboarding nudge" are mutually exclusive by construction.

Where it actually pays off

Not everything needs to be event-triggered. A weekly digest is genuinely a schedule, not a reaction. It's worth the setup when the email's relevance depends on what just happened, not just how much time has passed:

• Trial about to expire, but only if they haven't added a payment method. The event is "trial day 11 reached"; the useful part is that it's paired with account state, so you're not nagging someone who already upgraded.
• Cart or setup abandoned. "Started X, didn't finish" is inherently an event, not a date: there's no calendar day where abandonment happens on its own.
• A milestone worth celebrating or upselling. First successful send, hitting a usage tier, inviting a teammate. These are moments, not durations.
• Something failed and a human should hear about it fast. A payment declined, a sync broke. Speed is the point, and a nightly digest is too slow to matter.

If you're deciding between a scheduled step and an event, ask whether the email would still make sense if the timing were off by a day. If yes, a schedule is simpler and there's no reason to reach for events. If the email is wrong once the moment has passed, it needs to be triggered by the moment itself.

How the plumbing works

The shape is the same regardless of what triggered it: your backend posts a named event with whatever data made it worth sending, and that event does the rest.

POST /api/v1/events            scope: events:write
{
  "event": "trial.day_11_no_payment_method",
  "email": "[email protected]",
  "properties": { "trial_ends_on": "2026-09-24", "plan": "Growth" }
}

From there, the event name is the only thing that connects your backend to what happens next. A sequence with a custom event trigger bound to that name enrolls the contact, and everything in properties is available in the email as {{ event.trial_ends_on }} or {{ event.plan }}. If a property won't always be present, wrap the part of the sentence that depends on it in {% if %} rather than risk a sentence that reads like it's missing a word. See conditionals in merge tags.

The same event name can drive more than one thing at once: a sequence, a transactional email bound directly to that event, and a sequence goal that counts it as a conversion. They're independent, so a "payment failed" event can enroll someone in a dunning sequence and separately mark a "recovered" goal complete the moment a later payment.succeeded event arrives, with no code on your side tying the two together.

It's still marketing, not transactional

It's tempting to treat event-triggered mail as a technical cousin of a transactional receipt, since both fire off a backend event instead of a human clicking send. They're not the same bucket. A day-11 trial nudge still checks consent and still needs an unsubscribe footer, because nothing breaks if the recipient never sees it: they just miss a nudge you chose to send. See transactional vs marketing email for the full test if you're unsure which bucket a given message belongs in.

Starting small

You don't need to instrument every action in your product before this is useful. Pick the one moment where a fixed-schedule email is currently either wrong or silent (the trial nudge that fires regardless of payment status, the abandoned setup nobody follows up on) and post that one event. Settings, Events shows every event name you've sent and which sequences or goals are listening, so you can confirm your backend is posting what you think it is before you build the second one.

Start with the event-triggered sequences guide to wire up the sequence side, or events for the full payload and API reference.