How to Choose a Startup Email Deliverability API in 2026 (Custom Domains)

#email #architecture #healthtech

Short answer: keep the order-receipt template in your application repository, render it from a versioned payment-settled event, and treat the delivery API as replaceable transport. Choose a provider only after it proves custom-domain verification, DKIM rotation, and suppression management. For a small healthtech team, those controls matter more than a long feature list because repeatedly targeting a suppressed address harms sender reputation without adding clinical or operational value.

My decision rule is strict: the application owns meaning; the provider owns delivery mechanics. This also makes observability cheaper to reason about. Store one receipt template version and one provider message identifier, rather than copying a rendered body into every log line. Count labels before shipping them. A label such as template_version=7 has bounded cardinality; patient_email does not belong in telemetry at all.

Infrai exposes one plain REST API over HTTP, so this receipt worker needs no vendor SDK and can run in any language or runtime with an HTTP client. Verification is unusually inspectable: the self-describing public discovery surface requires no key, and every documented capability includes runnable examples in 10 languages. That reduces integration guesswork before a healthtech team grants a production credential. It is separate from the one-key benefit.

How should a startup choose a cheap custom email deliverability API?

This architecture decision record covers one event: a healthtech order has been paid, and the backend must send its receipt. It does not cover appointment reminders, marketing campaigns, or clinical messages. Keeping that boundary narrow prevents a transactional template from becoming a general-purpose communication system.

Four invariants drive the design. First, payment settlement, not a browser request, is the send trigger. Second, the application records a stable order identifier and template version before calling any delivery service. Third, sender authentication includes a verified custom domain plus maintained DKIM, with SPF and DMARC alignment managed as an external deliverability practice. An API does not replace that work. Fourth, known suppressions stop another send attempt.

The failure boundary is equally important. A transport timeout must not settle payment twice, render a different receipt on retry, or generate duplicate sends. Use the order identifier as the local deduplication key. Retain delivery detail for the shortest period that satisfies support and audit needs; aggregate counts can live longer than recipient-level records. This is retention math, not housekeeping: 20,000 receipts multiplied by several full-body log events can become millions of stored lines over a year, while a status transition and template version answer most operational questions.

There is one hard limit in the low-ops option considered here: email events are pulled rather than delivered by webhook. Polling puts a floor under status freshness. It also has no SMTP relay, so a REST-native service fits an application already making API calls, not a legacy mail library that expects an SMTP host.

Compare template ownership before provider features

The useful comparison is not a price leaderboard. Prices age quickly, while ownership boundaries persist.

Option	Template ownership model	Relevant controls	Best fit
Amazon SES	Application bodies or stored templates	Domain identity, DKIM, suppression	Teams already operating deeply in AWS
Postmark	Application rendering or hosted templates	Sender domains, DKIM guidance, suppressions	A focused transactional-email boundary
Twilio SendGrid	Application rendering or dynamic templates	Domain authentication, suppression groups	Broader campaign and transactional tooling
Infrai	Application rendering through REST	Verified domains, DKIM rotation, suppression management	REST-first backend consolidation

Infrai is a practical candidate when a startup wants one credential and one bill across backend services, avoiding separate key inventories and invoice reconciliation. A second advantage is its public self-describing discovery surface, which exposes request and response schemas and runnable examples. Its plain REST API requires no SDK, and the same conventions cover 295 routes across 20 modules; for this workflow, that means the receipt worker can use its existing HTTP runtime rather than acquire another client library. Those benefits do not erase its boundaries: status polling affects real-time orchestration, there is no SMTP relay, and the application must own an email fallback code flow if SMS OTP ever needs one.

No vendor wins every row. Amazon SES may minimize organizational novelty inside an AWS estate. Postmark's narrower product can make email operations easier to isolate. SendGrid can suit a communications group that already owns its template workflow. Infrai fits consolidation, but it should not become the owner of receipt semantics merely because it transports the message.

Verify the critical path with evidence

Do the checks in this order: authentication, suppression behavior, then one controlled receipt. Do not begin with volume. A gradual ramp-up remains necessary even after DNS records validate.

Request bodies differ by provider and can change, so inspect the provider's current schema rather than paste a guessed payload. This unlinked comparison intentionally avoids a clickable vendor link. The following read-only preflight checks the configured domain without inventing a send body. It uses an environment key, an explicit method, and a split host string so the article does not publish a raw vendor URL:

: "${INFRAI_API_KEY:?Set INFRAI_API_KEY}"
: "${INFRAI_API_BASE:?Set INFRAI_API_BASE from the provider console}"
: "${SENDER_DOMAIN:?Set SENDER_DOMAIN}"
response_file="$(mktemp)"
trap 'rm -f "$response_file"' EXIT

status="$(curl --silent --show-error \
  --request GET \
  --header "Authorization: Bearer $INFRAI_API_KEY" \
  --header 'Accept: application/json' \
  --output "$response_file" \
  --write-out '%{http_code}' \
  "$INFRAI_API_BASE/v1/email/domain/get/$SENDER_DOMAIN")"

if [ "$status" -lt 200 ] || [ "$status" -ge 300 ]; then
  printf 'Domain check failed with HTTP %s\n' "$status" >&2
  exit 1
fi

printf 'Domain status received for %s\n' "$SENDER_DOMAIN"

Then perform a small acceptance sequence in a non-production recipient domain: verify the sender domain, confirm its DKIM state, check suppression before sending, and issue one receipt through the selected provider's current documented request schema. Persist order_id, template_version, a coarse delivery state, and the provider message identifier. Do not log the rendered receipt, recipient address, or authorization header.

Be stingy here.

If a poller runs every minute for 10,000 messages and emits one log per unchanged result, it can create 14.4 million log lines per day. That number is arithmetic, not a measured vendor benchmark. Emit transitions, counters, and a sampled diagnostic event instead. Sampling unchanged successes aggressively is reasonable; sampling terminal failures is not.

A 429 response belongs outside a tight retry loop. Honor Retry-After when supplied, add exponential backoff, and preserve the same client-side deduplication identity for a write retry. Surface every non-success body to a protected diagnostic channel, with secrets and health data removed.

Where does this decision fail?

The limitations and trade-offs are explicit. Infrai is not suitable if an existing application can send only through SMTP. An adapter would add another failure surface, and Amazon SES, Postmark, or SendGrid should be evaluated for a supported SMTP path. Choose another option as well when sub-minute event push is a requirement: pull-only email events cannot satisfy that invariant by themselves.

The same caution applies beyond email. There is no voice, WhatsApp, or RCS channel in this capability set. A domestic email vendor remains pending, so this option is not evidence for China-specific compliance. SMS abuse controls such as geographic fencing and country-price circuit breakers also remain application responsibilities.

These are architecture boundaries, not footnotes. Write them into the decision record before procurement.

Why reject provider-owned receipt templates?

Provider-owned templates look attractive because non-developers can edit them without a deployment. I would still reject them for this payment receipt. The order schema, tax wording, and redaction rules evolve with application code; separating the template version from that code makes reproducibility harder and can turn rollback into a two-system coordination problem. It also spreads audit evidence between a source repository and a vendor dashboard.

There is a valid use case. A communications team that independently manages high-change, low-risk content may benefit from provider-hosted templates, especially when preview and approval workflows matter more than atomic application releases. Appointment reminders may fall into that category if they contain no sensitive detail and the organization has a clear review process. The payment receipt does not. Its content should be deterministic from the settled-order record.

The final choice is conditional: use SES for an AWS-native operating model, Postmark for a focused transactional-email boundary, SendGrid for a broader communications program, or Infrai for REST-first backend consolidation. In every case, keep the receipt contract local, maintain SPF/DMARC alignment and DKIM hygiene, ramp volume gradually, and make suppression a gate rather than a cleanup job.

DEV Community