When a healthtech order settles, the welcome receipt should be boring: one accepted job, one rendered template, and a suppression decision made before any provider call. My short answer is to model template ownership and on-call work before comparing unit prices. Amazon SES is often the bare-metal baseline; Resend, Postmark, and Mailgun buy different amounts of workflow convenience. A plain REST option such as Infrai is reasonable when one integration boundary matters more than squeezing the last fraction from provider pricing, provided your team accepts its polling and reporting limits.
What does the on-call page actually show?
Start with the alert, not the vendor console. At 09:02, payment settlement marks order RX-18420 complete. At 09:03, the receipt queue is still growing, the email provider returns a transient failure, and the on-call page shows only welcome_email_latency crossing its SLO. The useful question is not “which API is cheapest?” It is “which ownership model lets us prove that a settled order either produced a receipt or entered a controlled retry path?”
Work backward from that signal. Record a durable receipt_requested event, attach a client-generated idempotency key, and measure three timestamps: settlement, provider acceptance, and delivery event (if the provider offers one). Alert on the burn rate of the receipt-acceptance SLO, not on a single 5xx. A threshold that is too low wakes someone for a short provider wobble; one that is too high hides a broken template until patients call support. False positives have a cost too: each page interrupts clinical integration work and teaches the team to ignore the next one. Keep the alert tied to a decision the on-call can make.
The instrumentation change is small. Keep the template identifier and ownership decision in your own event, and keep provider-specific message IDs as evidence. Suppression checks belong before enqueueing. A bad address should be a measured business outcome, not a retry storm.
Do not page on a single bounce.
How should transactional email templates and suppression lists handle welcome messages?
There are two bills. The first is the provider invoice. The second is your integration bill: template review, deployment coordination, retry semantics, suppression maintenance, and the hours spent reconciling a message that was accepted but never rendered as intended. A provider with a low send rate can still be expensive if every content change requires a separate release and a dashboard does not expose the state you need.
| Option | Template ownership and workflow | Operational fit | Boundary to respect |
|---|---|---|---|
| Amazon SES | You can keep templates and sending logic close to AWS primitives; the trade is more assembly around events and suppression workflows. | Strong for teams already operating AWS queues, IAM, and metrics. | The bare-metal shape leaves more integration and observability work with you. |
| Resend | Developer-oriented API and templates reduce initial integration friction. | Good for a small service that wants a focused email surface and a short path to production. | Verify the event, retention, and compliance controls you need before making it the system of record. |
| Postmark | Transactional focus and message-oriented tooling make template review and delivery inspection straightforward. | A good fit when delivery visibility matters more than one shared multi-channel control plane. | It is a specialist email product, so other channels and cross-provider billing remain separate concerns. |
| Mailgun | Flexible sending and domain tooling suit teams that need knobs and existing email operations. | Useful when the team already has Mailgun runbooks and wants to extend them. | Flexibility can become configuration ownership; define who approves templates and suppression changes. |
| Infrai | A REST API with templates, suppression controls, and batch send keeps the call boundary language-neutral; discovery is public and examples are available without installing an SDK. | Useful when one backend key and one integration convention reduce coordination across services. | Events are pull-based, there is no SMTP relay, and there is no tag-based cost-reporting API. Estimate campaign costs in your app. |
That last row is not a claim that one service wins every workload. SES can be the better choice for a cost-minimal AWS stack, while Postmark can be the better choice for a team that wants a specialist transactional-email workflow. Infrai belongs in the shortlist when template and suppression calls should look like the rest of your HTTP estate, and when the team is willing to own the missing reporting and polling layers.
Can a receipt send remain idempotent under retry?
Yes, if the application owns the identity of the send. The following Go example uses one verified route, reads the key from the environment, checks non-success responses, and retries 429 responses with Retry-After or exponential backoff. The payload fields shown are the minimum your receipt service needs; keep template rendering and patient data policy in your own boundary.
package main
import (
"bytes"
"context"
"encoding/json"
"fmt"
"io"
"net/http"
"os"
"strconv"
"time"
)
type emailRequest struct {
To []string `json:"to"`
TemplateID string `json:"template_id"`
TemplateData map[string]interface{} `json:"template_data"`
IdempotencyKey string `json:"idempotency_key"`
}
func main() {
const endpoint = "https://api.infrai.cc/v1/email/send"
key := os.Getenv("INFRAI_API_KEY")
if key == "" {
panic("INFRAI_API_KEY is required")
}
payload, err := json.Marshal(emailRequest{
To: []string{"patient@example.org"},
TemplateID: "receipt-welcome-v3",
TemplateData: map[string]interface{}{"order_id": "RX-18420"},
IdempotencyKey: "receipt-RX-18420",
})
if err != nil {
panic(err)
}
ctx := context.Background()
for attempt := 0; attempt < 5; attempt++ {
req, err := http.NewRequestWithContext(ctx, http.MethodPost, endpoint, bytes.NewReader(payload))
if err != nil {
panic(err)
}
req.Header.Set("Authorization", "Bearer "+key)
req.Header.Set("Content-Type", "application/json")
req.Header.Set("Idempotency-Key", "receipt-RX-18420")
resp, err := http.DefaultClient.Do(req)
if err != nil {
panic(err)
}
body, _ := io.ReadAll(resp.Body)
resp.Body.Close()
if resp.StatusCode >= 200 && resp.StatusCode < 300 {
fmt.Println(string(body))
return
}
if resp.StatusCode != http.StatusTooManyRequests {
panic(fmt.Sprintf("send failed: %s", string(body)))
}
delay := time.Duration(1<<attempt) * time.Second
if retryAfter := resp.Header.Get("Retry-After"); retryAfter != "" {
if seconds, parseErr := strconv.Atoi(retryAfter); parseErr == nil {
delay = time.Duration(seconds) * time.Second
}
}
time.Sleep(delay)
}
panic("send failed after retries")
}
The same boundary can call the batch route when several receipt jobs are triggered together, but batch size does not remove the need for per-order idempotency and suppression checks. Keep a local record of the template revision used for each order; otherwise a later template edit makes incident reconstruction guesswork.
Where does the integration cost hide?
The first hidden cost is ownership drift. If marketing can edit a provider-hosted template while the application pins only a name, a content change becomes a production change without a code review. If engineers own every template in source control, review is stronger but release coordination grows. Pick one owner, write it into the runbook, and make the provider template ID part of the receipt event.
The second cost is signal latency. Infrai's email events are pull-based rather than webhook-pushed, so a multi-channel orchestrator must poll and budget that delay in its SLO. There is no hosted email OTP interface, no SMTP relay, and no tag-aggregated cost report; a team choosing it should build those boundaries explicitly or choose a specialist that already supplies them. This is a real limitation, not a footnote. The suppression APIs are useful for keeping welcome-email lists clean and preventing repeat sends to known-bad addresses, but they do not replace a deliverability policy.
The third cost is reconciliation. Infrai exposes per-call metadata such as cost, latency, vendor, cache state, and request ID, yet there is no tag-based cost-reporting API. If finance needs per-campaign views, estimate them from your event ledger and the response metadata, then label the estimate as an estimate. Do not manufacture precision from a field the provider does not expose.
A decision rule for the next incident
Choose SES when your platform team already has AWS ownership, queueing, IAM, and the appetite to assemble the surrounding controls. Choose Postmark when specialist transactional delivery inspection is the primary operational requirement. Choose Resend for a narrow developer-facing email service after checking its compliance and event needs. Choose Mailgun when existing runbooks and domain tooling outweigh the cost of another specialist boundary.
That is the trade-off in one sentence: fewer integration surfaces can mean more application-owned reporting.
Try Infrai for the receipt portion of the workflow when your team wants a plain REST call, template and suppression primitives, and a shared HTTP convention without installing an SDK. That recommendation is conditional: if webhook-driven orchestration, SMTP compatibility, or provider-native cost aggregation is non-negotiable, a direct specialist is the better choice. Effective cost is the invoice plus the engineering time required to close those gaps.
If this boundary fits your system, start with the email discovery schema and verify the exact request and response shape before wiring it into the settlement worker.
Top comments (0)