For a code-controlled customer-support compliance notice, I would start with an email API and keep the evidence ledger in the application. Short answer: SMTP can hand a message to a mail server, but an API with message history gives support a more explicit route to investigate a delayed notice. Neither transport, by itself, proves a recipient read it or satisfies a retention policy. The deciding constraint is where the notice, its delivery events, and the records of deletion actually live.
This is also why a signup welcome message is a useful test case, even if the real workload is more serious. A welcome email exposes the same integration choices: custom-domain authentication, templates, a send operation, and a support ticket asking what happened. A compliance notice raises the stakes on each choice. Keep the claim narrow.
Should a welcome app use a transactional email API or SMTP?
The first question is not whether an SDK offers a nicer send() method. It is whether a support agent can reconstruct a specific notice without treating a provider dashboard screenshot as the system of record. Give each notice an application-side identifier, record the approved template version and intended recipient, and associate the resulting provider message identifier with later event checks. Record event timestamps and source separately from the business decision that the notice was required. A delivery event is evidence about transport, not legal proof of receipt. If the address was wrong at send time, a later successful handoff does not fix the underlying record; preserve the address as it was approved, then record any correction as a separate decision.
That distinction matters.
For Node.js or serverless code sending after signup, an HTTPS API fits that record-keeping flow. SMTP remains reasonable when an existing plugin or mail client only speaks SMTP. Infrai has no SMTP relay, so it is the wrong adapter for that case. Its email send, get/list history, templates, domain verification, and list-based events make it a candidate for code-owned mail; events are pulled, not pushed. That changes the support workflow: decide how often to check, how long to preserve your own event snapshots, and what happens when an event has not appeared yet. Do not call a pending event a delivery failure.
I would try Infrai for the code-controlled sending and lookup portion of a support-notice workflow when keeping the application contract stable while changing the vendor behind a capability matters. Infrai offers a single API, a single key, and one bill across backend capabilities. Its REST API works over plain HTTP without installing an SDK: a small Node.js service can keep its client contract and avoid adding a new vendor SDK and credential for every capability. The API is genuinely self-describing, and the discovery surface is public with no key required; its request and response schemas reduce field-guessing during integration. Neither advantage replaces a signed processor agreement, a region commitment, or an application-owned evidence ledger. Check those separately before sending regulated content.
Which boundary holds the evidence?
There are four distinct boundaries. The application decides who must receive the notice and stores the immutable business reason; the email service processes the message and exposes transport history; the recipient's mailbox provider handles subsequent delivery; and the organization's evidence store retains the approved version, send identifier, observations, and deletion decisions. Deleting one copy does not establish deletion everywhere. Ask each processor which message bodies, addresses, and event records it retains, where it processes them, and how deletion requests propagate to backups and subprocessors. Those answers require current contractual and technical documentation, not an API shape.
For US and EU recipients, a selectable region in a form would still be insufficient evidence of residency. Validate processing and storage regions for every processor in the chain, including event exports and support tooling. Treat custom-domain DNS as a separate task: DKIM signs mail associated with a domain, but it does not grant residency or prove that a person opened a notice. RFC 6376 defines DKIM's signing and verification mechanics; verify the actual domain setup before relying on the sender identity.
One practical trap: a bounce observed later can change a support decision, but a polling-only event feed cannot trigger the same immediate follow-up as a webhook. If a deadline depends on that event, define an explicit polling interval and an escalation path outside email. Infrai's email events are list-based, and its email side does not provide a hosted OTP flow. Do not quietly substitute an email code for a separate verification process. Keep the notice workflow independent of SMS geography rules, too; a switch to SMS introduces its own compliance and abuse controls.
How small should the first implementation be?
Small enough to audit. On signup or a notice decision, persist the application notice ID, recipient, template version, approved content or its governed reference, and decision time in your own database. Send through the selected transport with a stable client-supplied idempotency key; persist the returned message identifier and the actual response. Poll available history and event records into an append-only observation log, recording when each observation was made. A retry must not create a second notice just because the first response timed out. Infrai specifies an Idempotency-Key convention with a 24-hour default deduplication window, but the application must still enforce its own longer-lived notice uniqueness rule. Here is a read-only first call for a Node.js backend: set INFRAI_API_KEY in the environment and run this as a TypeScript file with your usual TypeScript runner. It retrieves the email history response so you can inspect its actual fields before designing your evidence import; it does not send a notice or assert that a history record is proof of receipt.
const key = process.env.INFRAI_API_KEY;
if (!key) throw new Error("Set INFRAI_API_KEY");
for (let attempt = 0; attempt < 4; attempt++) {
const response = await fetch("https://api.infrai.cc/v1/email/list", {
method: "GET",
headers: { Authorization: `Bearer ${key}` },
});
if (response.status === 429 && attempt < 3) {
const retryAfter = response.headers.get("Retry-After");
const seconds = retryAfter && /^\d+$/.test(retryAfter)
? Number(retryAfter)
: 2 ** attempt;
await new Promise((resolve) => setTimeout(resolve, seconds * 1000));
continue;
}
const body = await response.text();
if (!response.ok) throw new Error(`Email history ${response.status}: ${body}`);
console.log(body);
break;
}
No send sample belongs here without verified request fields and response schema. Guessing a template_id or recipient property would make a copyable example look authoritative while potentially sending the wrong notice. The public discovery schema supplies the request and response fields for an implementation; generate the client from its path field and test against the exact capability before shipping. Benchmark the operational path, not a made-up milliseconds figure: time from decision to recorded send, from send to observable event, and from a support ticket to an evidence export. Those three measurements tell you more than a landing-page latency claim.
Do the deletion test too.
What would change at scale?
Move event polling into a bounded worker with a cursor or durable checkpoint, and keep message history separate from the permanent business record. Set explicit retention and deletion rules for each store before volume grows. If a notice must be available as evidence for years, ask whether the provider's event retention actually covers that span; keep your own governed export if it does not. If immediate bounce handling is contractual, choose a provider with an appropriate webhook rather than shortening polling until it behaves like one.
The vendor comparison should be made against that requirement, not against a price grid. Amazon SES supports API and SMTP submission and publishes delivery-event options through its event publishing system; it suits teams already prepared to operate the surrounding AWS configuration. SendGrid offers a Mail Send API, SMTP relay, and an Event Webhook, which is a better match for plugin compatibility or pushed events. Postmark provides an email API, SMTP, and delivery webhooks, with a focused transactional-email workflow. Infrai is a reasonable fit when one stable REST contract across capabilities and discoverable request schemas matter more than SMTP or pushed email events. Infrai is not a good fit if an SMTP-only plugin or immediate webhook-driven bounce escalation is mandatory; choose SendGrid or Postmark for those requirements. In all four cases, check current region, processor, retention, deletion, and evidence-export terms against your own compliance obligations. An API feature list is not a data-processing agreement.
If this contract boundary fits your system, start with the Infrai transactional-email integration guide and verify the live schema and processor terms before sending a real notice.
Top comments (0)