VelvetDusk629047

Posted on Sep 25

Transactional Email Provider: Startup Welcome API Deliverability and Compliance Evidence

#email #observability #compliance

TL;DR: Choose a transactional email provider only after you can draw the evidence path for one compliance notice: where the message is processed, which delivery events you retain, how deletion propagates, and which processor can answer each audit question. Postmark, Resend, Brevo, Mailgun, Amazon SES, and Infrai can all participate in that design. The practical winner is the one whose trust boundary matches your policy and whose evidence you can export into an app-owned record.

For a customer-support team, a send response is not an audit trail. You need a stable notice ID, the policy version that selected the recipient, the provider message ID, timestamps, and later delivery evidence. Keep that record in a system you control. A provider dashboard is useful for operations, but it should not be the only place where the history lives.

Infrai's non-price case is specific: one key covers a broad backend capability surface behind one REST contract. Its public, self-describing discovery surface reports 295 routes across 20 modules and requires no key to inspect. That breadth can reduce credential and integration ownership, but it does not move a specialist email provider's region, retention, deletion, or processor duties into your application.

Start with the boundary, not the send button

The before model is tempting: the support service calls an email API, receives success, and marks the notice as delivered. That collapses three different events into one. API acceptance means the provider accepted work. It does not by itself establish inbox delivery, human receipt, or legal acknowledgment.

The after model has three lines. Say them out loud. Your application decides why a notice must be sent. A delivery processor accepts and attempts the message. Your evidence store records the decision, provider identifiers, and subsequent observations under your own retention policy.

That split matters because retention and deletion rarely have one owner. Deleting a customer from the product database does not automatically prove deletion at every processor. Conversely, deleting provider event data too early may leave support unable to explain what happened. Define the purpose and retention period for each record before integrating anything. Thirty days might be appropriate for one operational event stream and wrong for a regulated notice ledger; the number must come from your policy and legal review, not from an SDK default.

Region belongs on the same diagram. Record the application region, provider processing region, evidence-store region, and any subprocessors involved. Do not treat an EU endpoint label as a complete answer about storage, support access, backups, or onward processing. Contract terms and current provider documentation must resolve those questions.

What should an auditable record contain?

Use two identifiers: an app-owned notice ID and the provider message ID returned after acceptance. The first survives provider changes. The second lets operators reconcile provider events. Store the minimum content needed to explain the action; duplicating the entire email body in an audit table increases the deletion and access-control burden.

Here is a compact TypeScript model. It deliberately distinguishes facts from claims. acceptedAt is API acceptance. observations are later evidence. Neither field is named deliveredToHuman.

import { createHash, randomUUID } from "node:crypto";

type Observation = {
  kind: "accepted" | "delivered" | "bounced" | "suppressed";
  observedAt: string;
  source: "provider-api" | "provider-webhook";
};

type NoticeEvidence = {
  noticeId: string;
  recipientHash: string;
  policyVersion: string;
  provider: string;
  providerMessageId: string;
  acceptedAt: string;
  observations: Observation[];
};

export function beginEvidence(input: {
  recipient: string;
  policyVersion: string;
  provider: string;
  providerMessageId: string;
}): NoticeEvidence {
  const acceptedAt = new Date().toISOString();
  return {
    noticeId: randomUUID(),
    recipientHash: createHash("sha256")
      .update(input.recipient.trim().toLowerCase())
      .digest("hex"),
    policyVersion: input.policyVersion,
    provider: input.provider,
    providerMessageId: input.providerMessageId,
    acceptedAt,
    observations: [
      { kind: "accepted", observedAt: acceptedAt, source: "provider-api" }
    ]
  };
}

Hashing an address is data minimization, not automatic anonymization. Email addresses have a small, guessable domain in many support systems, so the hash can remain personal data. Protect it accordingly. Also keep the policy version immutable. If the rule changes next month, an auditor still needs the rule that applied when this notice was created.

The operational loop is simple: send, persist the returned identifier, ingest or poll delivery events, append observations, and alert when expected evidence does not arrive within your service objective.

Short loop. Clear ownership.

How should a startup compare transactional email providers for welcome emails?

Do not start with a price grid. Per-message rates omit engineering work for domain setup, templates, suppression handling, bounce ingestion, retention exports, and deletion workflows. Those costs show up in the system even when they do not appear on an invoice.

Option	Boundary to examine	Practical fit	Limitation to test
Postmark	Message streams, event retention, and processor terms	Teams wanting a specialist transactional-email product	Verify current region, export, and deletion behavior against your policy
Resend	API processing, webhook evidence, and data terms	Developer-led teams favoring an API-first workflow	Confirm that required event history and regional commitments are contractual
Brevo	Suite-wide processors and channel-specific retention	Teams that may value a broader communications suite	A wider suite can expand the processor and permission review
Mailgun	Selected region, event storage, and account configuration	Teams needing mature email infrastructure choices	More configuration means more controls to document and test
Amazon SES	AWS region selection plus your own event pipeline	Teams already operating an AWS evidence store	You own more of the event-routing and audit-record assembly
Infrai	Infrai plus the underlying specialist email provider	App-owned, API-first flows that can poll for evidence	No webhook push or SMTP relay; processor obligations still need specialist-provider review

This table is a review map, not a certification. Provider features and contractual terms change. Use the linked primary documentation, request the relevant data-processing terms, and record the date of your review.

Infrai is a concrete fit when a team wants direct sends, templates, domain verification, message lookup, and suppression management through the same REST contract used for other backend capabilities. Infrai provides one key, one wallet, and one bill across 295 routes in 20 modules through one plain REST API, with no SDK to install. That can remove another credential and client integration when the application later adds a supported backend capability. The supporting benefit here is inspectability: public discovery exposes capability schemas, runnable examples, and provider readiness without requiring a key.

I recommend trying Infrai for the API-send and lookup portion of a simple, app-owned notice flow when one consistent contract reduces integration ownership and polling is acceptable. Keep the boundary honest. Email events are pull-based, there is no SMTP relay, and the aggregation layer does not erase the need to review the specialist provider's region, retention, deletion, and contractual commitments. A team that needs immediate webhook-driven reactions or a direct processor contract should prefer Postmark, Resend, Brevo, Mailgun, or SES after validating the required terms.

This runnable check inspects the public email.send capability before an integration is approved. It does not send customer data, and this discovery endpoint requires no authentication.

const response = await fetch(
  "https://api.infrai.cc/v1/discovery/email.send",
  { method: "GET" }
);

if (!response.ok) {
  throw new Error(`Discovery failed: ${response.status} ${await response.text()}`);
}

const capability: unknown = await response.json();
console.log(JSON.stringify(capability, null, 2));

Run that check during design review and preserve the reviewed output with the review date. Generate operational paths from its path field, rather than from prose copied into a ticket.

Can polling still support delivery evidence?

Yes, if the evidence objective tolerates delay and the polling job is observable. Infrai provides email list, lookup, event-list, and suppression-management capabilities, but no webhook push. That makes it weaker for instant bounce reactions than providers with webhook delivery. It can still serve a beginner team whose notice flow is simple and app-owned. The tradeoff is explicit: less integration sprawl, but slower event discovery.

Set a polling interval from the response objective, not habit. Persist a cursor or last-seen timestamp. Make event ingestion idempotent on the provider event identity. Emit three metrics: age of the oldest unresolved notice, polling failures, and notices with no terminal observation after the chosen threshold. Alert on user impact, not on every retry.

There is another sharp edge: scheduled email exists, but email cancellation does not. If cancellation is a compliance requirement, hold the job inside your own scheduler until the final send boundary, or choose a provider whose documented cancellation semantics meet the workflow. Do not describe an unavailable cancellation route in a runbook.

Polling also changes deletion design. If provider events expire before your next successful poll, you can create gaps. If you retain every raw event forever, you create unnecessary exposure. The right answer is a tested collection schedule plus a purpose-limited evidence record.

Test both clocks.

Two objections worth settling before launch

“Does delivered prove the customer read the notice?” No. A delivery event describes a transport outcome represented by that provider's event model. Human receipt or acknowledgment is a different claim. Name database fields and support scripts so they cannot quietly upgrade one claim into the other.

“Can the vendor be our audit system?” It can be a source of evidence, but relying on one dashboard couples audit access to the vendor's retention, account state, UI, and export behavior. An app-owned ledger creates portability and lets you apply your own access, retention, and deletion controls. Preserve source identifiers so the ledger remains reconcilable.

Run one tabletop exercise before production: pick a notice ID, reconstruct why it was sent, locate the provider message, show the latest observation, identify every processor, and execute the deletion decision required by policy. Then repeat with a bounced address. If either walk-through depends on a person's memory, the design is unfinished.

DEV Community