Most transactional-email senders only render plain HTML. POST /api/v1/send in template mode instead renders one of your own studio projects — full fallback engine and interactive blocks included — so a receipt or confirmation your backend triggers can carry a Rating block or a Product upsell exactly like a marketing send would.
A receipt is one of the highest-open-rate emails a company sends — and almost always the plainest, because it's usually generated by whatever transactional library was easiest to wire up, not by anything with a design system attached.
Design it once, trigger it from your backend
Build the receipt or confirmation as a normal studio project, with whichever blocks make sense — a Rating for post-purchase CSAT, a related-item Product upsell. Your backend then calls the Send API in template mode with the project's ID and a mergeData object standing in for that specific order's dynamic values.
Mark it transactional, correctly
Setting type to "transactional" bypasses unsubscribe-suppression — a receipt still needs to reach someone who opted out of marketing — but never bounce-suppression, since a genuinely bad address shouldn't keep being sent to regardless of email type.
It's authenticated like any API integration
A per-owner named API key, Bearer-authenticated, mints and revokes from the Developers section of the dashboard. An Idempotency-Key header keeps a retried request from sending the receipt twice.
What doesn't carry over
Freeform mode (no projectId, just raw html/text) skips the rendering pipeline entirely — no merge tags, no fallback engine, sent exactly as given. That's the right choice for something like a one-off OTP code; template mode is what's worth using once the email itself benefits from an interactive block.
Getting started
Build the transactional template as a studio project with the interactive blocks you want, mint an API key under Developers, and call POST /api/v1/send in template mode with your mergeData and type: "transactional".