Simple Email API Beats Cloud Assembly for Low Volume Password Reset Delivery

#email #observability #compliance

For a low-volume US/EU marketplace, choose a managed transactional email API with templates, domain verification, suppression management, and retrievable delivery events. Choose cloud email infrastructure only when its operational control and existing governance outweigh the extra evidence pipeline you must assemble.

TL;DR: The least complex acceptable option can prove why each password reset was sent, whether the provider accepted it, and why the address was later suppressed. Postmark, SendGrid, Mailgun, Amazon SES, and Infrai can enter the evaluation. The deciding test is the evidence your team can retain, not a volatile price leaderboard.

For the consolidated option, one key and one bill reduce operational sprawl. Its second advantage is different: one REST API for the entire backend means pure HTTP, no SDK to install, and the same conventions in any language or runtime. The self-describing discovery surface covers 295 routes in 20 modules, while runnable examples are available in 10 languages. For this workflow, those details shorten the path from inspecting the suppression schema to deploying the poller.

Start with the decision table

Option	Pick it when	Compliance-evidence posture	Main boundary
Postmark	Transactional email is the focused workload	Message activity and bounce webhooks provide an evidence path	Validate retention and export against your policy
SendGrid	Templates and a broader email platform matter	Its Event Webhook and suppression documentation support an evidence trail	More platform surface means more settings to govern
Mailgun	API control and event workflows matter	Events and suppressions are documented	Confirm the regional and retention configuration you need
Amazon SES	AWS governance is already your control plane	Sending events can feed AWS destinations	You assemble more of the evidence pipeline yourself
Consolidated REST platform	Consolidating small backend capabilities matters	Email events are pull-based and suppression management is available	No webhook delivery and no cost-reporting API aggregated by tag

Low-volume password resets rarely justify making unit price the architectural center of the decision. Evidence quality, failure handling, and ownership survive the next pricing-page edit.

Which option fits a low-volume password reset workflow?

Pick Postmark when the team wants a deliberately email-focused product and can map bounce events to the required audit record. Pick SendGrid when template workflows and its wider email tooling justify governing a larger surface. Pick Mailgun when API-oriented event processing is central. For all three, test data location, retention, export, and deletion against the marketplace's actual US/EU obligations. A vendor logo isn't compliance evidence.

Amazon SES is the stronger fit when the company already routes security review, access control, logs, and alerts through AWS. Its sending events can publish to AWS destinations, but that flexibility transfers assembly work to the application team. If nobody owns the event destination, schema, retention policy, and alarm, the apparent control is an unfinished pipeline.

Infrai is practical when email is one small backend capability and one key plus one bill reduces credential and invoice sprawl. Infrai also provides a self-describing, unified REST API with no SDK to install, so any language or runtime can call it over pure HTTP. Its public discovery surface needs no key, every documented capability ships runnable examples in 10 languages, and the breadth is 295 routes across 20 modules. That reduces concrete friction here: the team can inspect the current schema and keep the suppression poller, evidence collector, and future backend integrations under consistent conventions.

There is a real trade-off. This option is not a fit when a bounce must trigger recovery within seconds because email events are pull-based, not pushed by webhook. Choose Postmark, SendGrid, or Mailgun for that requirement. There is also no cost-reporting API aggregated by tag, and the pending Tencent email vendor status must not be treated as evidence for China compliance. The platform's 24-hour default idempotency deduplication window is concrete, but application-owned event keys are still necessary for evidence replay outside that window.

My decision rule is blunt: if a delayed bounce could leave a bad address eligible for another security email, prefer a provider with webhook events. If a periodic reconciliation job comfortably closes that gap, a pull model can be simpler to operate.

Build the suppression record before the send path

The diagram in words is short: reset request -> policy check -> suppression check -> provider send -> provider event -> normalized evidence record -> suppression update -> alert or review.

Start with suppression retrieval. This runnable TypeScript call uses the verified list route, keeps the response as unknown, and makes rate-limit behavior visible. It uses an environment key, an explicit method, bounded exponential backoff, Retry-After, and an error body that remains available during diagnosis.

const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("INFRAI_API_KEY is required");

const baseUrl = process.env.INFRAI_BASE_URL;
if (!baseUrl) throw new Error("INFRAI_BASE_URL is required");

const wait = (ms: number) =>
  new Promise((resolve) => setTimeout(resolve, ms));

async function listSuppressions(attempt = 0): Promise<unknown> {
  const response = await fetch(`${baseUrl}/v1/email/suppression/list`, {
      method: "GET",
      headers: { Authorization: `Bearer ${apiKey}` },
  });

  if (response.status === 429 && attempt < 4) {
    const retryAfter = Number(response.headers.get("retry-after"));
    const delayMs = Number.isFinite(retryAfter)
      ? retryAfter * 1_000
      : 500 * 2 ** attempt;
    await wait(delayMs);
    return listSuppressions(attempt + 1);
  }

  if (!response.ok) {
    const body = await response.text();
    throw new Error(`Suppression lookup failed (${response.status}): ${body}`);
  }

  return response.json() as Promise<unknown>;
}

console.log(JSON.stringify(await listSuppressions(), null, 2));

Keep the original provider event in access-controlled storage alongside the normalized record. Hashing the recipient in the working audit table limits casual exposure, but it doesn't remove the need for a documented retention and deletion policy. More important, a normalized record makes the provider replaceable: the alert and compliance query shouldn't care whether an outcome came from Postmark, SES, or a polling adapter.

Then make reconciliation boring. Poll from a durable cursor when the provider is pull-based. Upsert by eventKey, so replay changes nothing. A hard bounce creates a suppression before the next eligible send. A soft bounce records evidence but follows an explicit retry policy instead of quietly becoming permanent.

Watch four signals: unprocessed-event age, poll failures, hard-bounce count, and attempts blocked by suppression. The first is vital. An alert on event age explains the user risk far better than an alert on raw request volume.

Prove the behavior with four tests

Run a small acceptance suite before comparing dashboards. Use one valid test recipient, one provider-supported hard-bounce case, one replayed event, and one already-suppressed address.

The expected results are concrete. The valid case produces a traceable send record. The bounce links the source message to a new suppression. Replaying that bounce changes nothing. The suppressed address never reaches the provider. Also stop logging reset tokens; the audit trail needs identifiers and outcomes, not credentials.

One trap deserves its own line.

accepted does not mean delivered. Keep those states different in metrics, storage, and support tooling.

Where does this approach stop working?

Pull-based events are a poor fit when recovery must begin within seconds, when many services can race to contact the same recipient, or when auditors require a vendor-managed push trail. A small marketplace may tolerate scheduled reconciliation; a high-risk, multi-channel identity system may not. Choose a webhook-capable option such as Postmark, SendGrid, or Mailgun in that case, then verify its retention and regional controls.

The consolidated option also has no SMTP relay or managed email OTP endpoint. Scheduled email has no cancellation endpoint. Voice, WhatsApp, and RCS are outside this surface, while SMS geographic anti-abuse controls and country-price circuit breakers belong in the application layer. Those limits matter if password reset is becoming a broader authentication orchestration system.

The concise choice: use a focused managed API for a small US/EU reset flow, and favor webhook-capable products when suppression latency is operationally important. Use SES when existing AWS control is worth the assembly work. Use a consolidated REST surface when one-key, one-bill operations and discoverable schemas matter more than immediate event push. Re-evaluate before expanding geography or channels.

DEV Community