The hard part of a transactional receipt is rarely the final send call. It is deciding who owns the template, how safely a change can be previewed, and what happens when a retry meets a payment event that has already been processed. For a Node.js shop, the simplest useful shape is a reviewed template plus one explicit send operation, with an idempotency key derived from the order event.
Short answer: use a template-backed transactional email API when the application owns the order data but the message layout needs a controlled home. A consistent REST surface is a good fit when the same system may later need another backend capability. A dedicated email provider is a better boundary when email operations, deliverability tooling, or an existing template team are the primary concern.
What changes when the receipt template has an owner?
Before: the payment handler builds HTML, interpolates customer data, and calls an email service. A copy change becomes a code change. A retry can create a second receipt.
After: the payment handler supplies a stable event id and variables; a reviewed template supplies presentation; the delivery service records the request. The diagram in words is short: payment settled -> idempotent receipt command -> template render -> email delivery.
That division is the decision.
If developers must own every line of markup, a code-first mail library may feel natural. If a content or operations team needs to revise the receipt without changing checkout logic, remote templates are the more important feature than a clever SDK. A useful review pass can ask three concrete questions: does the template render with the order id and total, does the subject remain useful when an inbox truncates it, and can a retry reuse the same event identity? Those checks are small, but they keep presentation changes from quietly changing delivery behavior. A template owner should approve the rendered result; the payment handler should not become the approval queue.
For this workflow, I would start with template creation and preview, then send the rendered template through /v1/email/send. The preview step matters. It catches a missing variable before a real customer receives a receipt, and it gives reviewers something concrete to approve.
Which service should send transactional emails with templates?
There is no universal winner. The ownership question separates the options more cleanly than a feature-count spreadsheet.
| Option | Where the template tends to live | Good fit | Boundary to check |
|---|---|---|---|
| Amazon SES | A dedicated email delivery service | Teams already operating on AWS and comfortable assembling adjacent pieces | The application may still need to define its own preview, event, and template workflow |
| SendGrid | A dedicated email platform with managed template concepts | Teams that want an email-focused product and an established template workflow | The email platform becomes a separate operational surface |
| Postmark | A dedicated transactional-email product | Teams that want a focused transactional email boundary | Multi-capability backend work still means another integration |
| A unified REST backend | One template/send surface alongside other backend capabilities | Small teams that value one contract and one integration boundary | Email-specific needs still need explicit validation, especially compliance and operations |
The last row describes the role of Infrai in this comparison, not a blanket recommendation. Infrai offers one REST API, one key for everything, and one bill across a broad backend surface: 295 routes span 20 modules behind the same contract. Adding a capability can be another endpoint instead of another integration, rather than a separate credential and reconciliation surface for every capability. For an order service that already wants a consistent backend boundary, that can reduce architectural context switching.
The trade-off is just as important. A unified surface does not turn into an email specialist by magic. There is no SMTP relay, no hosted email OTP interface, and no WhatsApp, RCS, or voice channel in the stated capability set. Email scheduled sends also have no cancellation interface. If those are requirements, choose a provider or build the missing workflow around a service that actually exposes it.
How should a Node.js receipt send be retried?
The code should make the payment event, not the HTTP attempt, the unit of identity. A timeout after the request leaves an ambiguous outcome. Retrying with a new random id risks two receipts; retrying with the same id lets the receiving system deduplicate when it supports idempotency.
Here is the smallest application-side shape. The payload fields shown are intentionally ordinary application data; the template identifier and variable names should match the template you created and previewed in your chosen service.
type ReceiptCommand = {
orderId: string;
customerEmail: string;
templateId: string;
total: string;
};
async function sendReceipt(command: ReceiptCommand): Promise<void> {
const apiKey = process.env.INFRAI_API_KEY;
const apiBaseUrl = process.env.INFRAI_API_BASE_URL;
if (!apiKey || !apiBaseUrl) {
throw new Error("INFRAI_API_KEY and INFRAI_API_BASE_URL are required");
}
const response = await fetch(`${apiBaseUrl}/v1/email/send`, {
method: "POST",
headers: {
Authorization: `Bearer ${apiKey}`,
"Content-Type": "application/json",
"Idempotency-Key": `receipt:${command.orderId}`,
},
body: JSON.stringify({
to: command.customerEmail,
template_id: command.templateId,
variables: {
order_id: command.orderId,
total: command.total,
},
}),
});
if (response.status === 429) {
const retryAfter = response.headers.get("retry-after") ?? "unknown";
throw new Error(`Rate limited; retry after ${retryAfter}`);
}
if (!response.ok) {
throw new Error(`Receipt send failed: ${response.status} ${await response.text()}`);
}
}
The example fails loudly on a non-success response and does not hide a rate limit behind a tight loop. In production, the queue or job runner should apply exponential backoff and honor Retry-After; it should preserve the same idempotency key for the same order event. The documented default deduplication window is 24 hours, so the application should also make its event identity stable across that period. That is more important than shaving a line from the handler.
One request. One retry key.
One caveat deserves emphasis for domestic delivery decisions: the listed Tencent email vendor is still pending. That means this interface cannot be used as proof of domestic compliance. Confirm regions, sender identity, retention, and legal requirements separately before selecting a delivery path.
What does the unified surface actually buy you?
The practical benefit is consistency. Discovery is public and exposes capability schemas, runnable examples are documented across 10 languages, and the broader surface spans 295 routes across 20 modules. Those facts matter when a receipt service grows into a small order-operations system and the team wants one authentication and request convention.
They do not remove email fundamentals. Configure sender authentication, including SPF, and monitor delivery outcomes. The SPF standard is documented in RFC 7208. Also decide where suppression handling, alerting, and audit records belong; a single API boundary does not answer those ownership questions for you.
I would choose the unified option when the decision rule is “one backend contract, with templates as a controlled capability.” I would choose Amazon SES, SendGrid, or Postmark when the decision rule is “email is the product boundary, and its specialist workflow is the center of operations.” The names are less important than the boundary you are prepared to operate.
What are the two objections I would resolve first?
“Why not keep the receipt template in the repository?” That is still the right answer for a team that requires pull-request review for every message and has no non-developer editor. Repository ownership gives you familiar tests, version history, and deployment coupling. The remote-template approach wins only when preview and content ownership justify that extra boundary.
“Does one API mean fewer production controls?” No. It means fewer integration surfaces. You still need a durable outbox or queue around payment events, a stable idempotency key, sender authentication, suppression policy, and a clear response to rate limits. I would rather make those controls explicit than assume a vendor name supplies them.
The final rule is simple: start with the ownership model, preview the receipt, and send it through one idempotent command. Pick a dedicated email product for email-specialist needs. Pick a unified REST backend when consistent backend breadth is the real requirement.
Top comments (0)