Prerequisites
- A verified sending domain and a secret key.
- Consent to email the buyer (collected at checkout or signup).
Build it
1
Send the purchase event from your backend
When your checkout succeeds, send a
purchase_completed event. Put the order facts in payload (they stay with the event) and buyer traits in attributes (they attach to the contact).The
idempotencyKey (here order:A-1024) stops a retried request from sending two confirmations for one order. Build it from something stable like the order id. See Idempotency.2
Confirm the order
Build an automation that triggers on
purchase_completed and sends a confirmation email, personalized with the order_id and total_usd from the event.trigger (purchase_completed) → send email (Order confirmed)3
Follow up to drive the next purchase
Extend the flow with a wait and a nudge:
→ wait 5 days → send email (You might also like…)Branch on total_usd to treat big-ticket buyers differently from small ones.4
Activate and publish.
As with any automation, both are required.
Test
Send the event with your own email and a testorder_id, then confirm the confirmation email arrives and reads correctly. Re-send the same idempotencyKey to prove a duplicate doesn’t double-send.
Measure
- Confirmation deliverability (it should be near 100%; a confirmation that bounces is a support ticket).
- Repeat purchase rate among people who entered the follow-up.
- Revenue attributed to the follow-up email via the campaign report.
Variations
- Refunds and cancellations. Send
purchase_refundedand branch to a different message. - Post-purchase onboarding. For software, chain the confirmation into a short “get the most from it” series.
- Web3 parallel. For an on-chain purchase, see On-chain purchase follow-up.

