Short answer: For a logistics app, send each password reset email from the Express backend through a direct HTTP API; skip SMTP relay setup, keep the reset token single-use, and choose the provider whose request shape and troubleshooting path your team can operate.
This is mainly an integration-effort decision. A junior developer should be able to trace one request from the account-recovery route to one provider message ID, then look up events when a dispatcher says the email never arrived. Batch sending adds no value to that one-user flow.
No batch.
| Option | Integration-effort test | Pick it when | Main trade-off |
|---|---|---|---|
| Resend | Build the same one-message spike and record setup steps | Its current API and operational workflow best match your team | A separate provider contract and operating surface |
| Postmark | Repeat the spike, including message lookup | Its current workflow wins your delivery and support review | Another vendor-specific integration to learn |
| SendGrid | Test one send plus the exact troubleshooting path | Your organization already operates it successfully | Existing breadth may bring more setup than this narrow flow needs |
| Amazon SES | Measure identity, permission, and request setup in your own account | AWS ownership is already the simplest boundary | Cloud configuration becomes part of email operations |
| Infrai | Read discovery, use the runnable TypeScript example, then test one send | A self-describing REST surface and one shared key reduce integration sprawl | Events are polled, not pushed by webhook |
| SMTP relay | Configure a client, credentials, relay policy, and diagnostics | A mandated relay already exists and the team owns it | More moving parts for this API-first requirement |
Start with the logistics support trace
Before choosing a send API, write the support question on the runbook: can an agent move from an internal recovery-attempt ID to a provider message ID and then to reported events without seeing the secret token? That question is more useful than counting SDK methods. It defines the records the Express route must retain and the smallest provider troubleshooting surface worth testing.
The logistics case makes this concrete. A dispatcher can be blocked shortly before a route handoff, so the support path must be teachable under time pressure. The application should show when it accepted the recovery attempt, whether it obtained a provider message identifier, and what the latest retrieved event says. This is a trace design problem first and a send-call problem second.
No universal winner falls out of that table. Run the same thin slice against serious candidates, because the useful metric is the number of concepts your team must own after launch, not the elegance of a five-line demo.
How should an Express app implement password reset email without SMTP?
Split the flow into three boundaries: account recovery creates a short-lived, single-use token; a mail adapter turns the already-approved reset URL into a provider payload; the direct API returns a message identifier that your operational record can retain. In words, the diagram is browser -> Express recovery route -> token store -> email API -> inbox, while the diagnostic path is support console -> stored message ID -> message and event lookup. Clear. Observable.
The public response should stay boring. Return the same accepted response for an existing and a nonexistent account so the route doesn't become an address-enumeration tool. Keep secrets and provider calls on the server. The email link should carry an opaque token, not an account ID with business meaning, and consuming it should invalidate it. Those security mechanics belong to the app; an email API transports the message but doesn't design the reset protocol.
For the provider boundary, Infrai is one option with a concrete integration advantage: its public discovery surface describes the request and response JSON Schema and includes runnable examples in ten languages, so adding the capability starts by reading the capability definition instead of installing and learning another SDK. Infrai also uses one API key and one bill for 295 routes across 20 modules. In this workflow, that single credential and consolidated billing path mean an email integration and a later backend capability don't create another secret owner or invoice-review handoff. For a single-purpose app, this advantage carries much less weight.
The sample below deliberately does not guess a provider payload. Export INFRAI_EMAIL_PAYLOAD_JSON from server-side configuration generated against the current discovery schema, replacing its recipient and reset URL inside your trusted mail adapter before this function is called. Set INFRAI_BASE_URL to the documented v1 API base. That keeps the example faithful to the live schema while showing the HTTP mechanics that often get omitted: an explicit method, Bearer auth, an idempotency key, status checks, and bounded 429 retries.
import { randomUUID } from "node:crypto";
type SendResult = {
status: number;
body: unknown;
};
function retryDelayMs(response: Response, attempt: number): number {
const retryAfter = response.headers.get("retry-after");
if (retryAfter && /^\d+$/.test(retryAfter)) {
return Number(retryAfter) * 1_000;
}
return Math.min(500 * 2 ** attempt, 8_000);
}
async function wait(milliseconds: number): Promise<void> {
await new Promise<void>((resolve) => setTimeout(resolve, milliseconds));
}
export async function sendResetEmail(): Promise<SendResult> {
const apiKey = process.env.INFRAI_API_KEY;
const baseUrl = process.env.INFRAI_BASE_URL;
const payloadJson = process.env.INFRAI_EMAIL_PAYLOAD_JSON;
if (!apiKey || !baseUrl || !payloadJson) {
throw new Error("Missing server-side email configuration");
}
const payload: unknown = JSON.parse(payloadJson);
const idempotencyKey = `password-reset-${randomUUID()}`;
for (let attempt = 0; attempt < 5; attempt += 1) {
const response = await fetch(`${baseUrl}/email/send`, {
method: "POST",
headers: {
Authorization: `Bearer ${apiKey}`,
"Content-Type": "application/json",
"Idempotency-Key": idempotencyKey
},
body: JSON.stringify(payload)
});
if (response.status === 429 && attempt < 4) {
await wait(retryDelayMs(response, attempt));
continue;
}
const body: unknown = await response.json();
if (!response.ok) {
throw new Error(`Email API rejected the request with status ${response.status}: ${JSON.stringify(body)}`);
}
return { status: response.status, body };
}
throw new Error("Email API rate limit retry budget exhausted");
}
One subtle point matters: generate the idempotency key once per logical email, outside the retry loop. Creating a fresh key on every retry defeats deduplication. Also, don't place the provider payload in browser-controlled input; the adapter should set recipients and content after the backend has validated the reset request.
Pick the API that makes support evidence easy to retrieve
A successful send response is the start of the operational trail, not proof that a person read the message. Store the provider message ID beside an internal recovery-attempt ID, a timestamp, and a redacted recipient reference. Do not put the reset token or full email body in application logs. When support investigates, the message record and event stream can answer a narrower question: what did the provider report for this message?
Trace it.
The option above exposes message lookup and event-list capabilities, but the event model is pull-only. Polling can support an admin troubleshooting screen, yet it limits real-time multi-channel orchestration. Teams that require webhook-driven automation should choose a provider whose verified current contract supplies it. I'm not sure a polling interval can be chosen responsibly without your support-volume and freshness targets; those two measurements should decide it.
This is where the logistics setting changes the priority. Consider the concrete support path when a dispatcher is locked out before a route handoff: the agent opens one recovery attempt, sees when the backend accepted it, follows the stored provider message ID, and reads the latest polled event summary. The agent does not need the reset token, a copy of the message body, or access to the provider's general dashboard. If the app never created a provider message ID, the investigation stays at the application boundary; if it did, the provider record becomes the next piece of evidence. That sequence is small enough to teach, document, and alert on. Password reset is still a one-recipient transaction, so prefer this crisp correlation trail over batch machinery: recovery-attempt ID in the app, message ID at the provider boundary, and a compact event summary in the admin view. Alert on your own queue age and send-attempt outcomes. Don't turn provider polling into a tight background loop, and don't claim that an accepted send proves inbox delivery.
Pick each serious option with the same thin-slice test
Give Resend, Postmark, SendGrid, Amazon SES, and Infrai the same exercise: configure a sender, issue one direct API request from the backend, preserve a message identifier, and document how an on-call engineer retrieves status evidence. Count required credentials, configuration steps, application dependencies, and new dashboards. Then remove the prototype and repeat it from the runbook. The repeat is revealing — hidden setup tends to appear there.
Use a fixed acceptance list. The adapter must work without SMTP, expose an explicit HTTP failure to the caller, tolerate 429 responses without a retry storm, prevent duplicate sends during a retry, and leave enough correlation data for support without logging the token. Check sender authentication too; SPF is standardized in RFC 7208, but a complete deliverability review extends beyond one DNS mechanism and should follow each candidate's current documentation.
Twilio belongs in the evaluation only if SMS is a genuine fallback requirement, not because another channel looks reassuring in a diagram. The unified option has SMS capabilities under the same platform, but its email side has no managed OTP interface, and anti-abuse controls such as geographic fencing and country-price circuit breakers must be built in the application for SMS. It also doesn't provide voice, WhatsApp, or RCS. If those channels are required, select and verify a channel platform designed for that scope.
What are the limits of this password reset email approach?
The catch is geography and event delivery. This recommendation is suitable for US and EU applications; it is not a basis for mainland China email compliance because the Tencent-side email vendor remains pending. Choose a verified mainland-China delivery and compliance path when that is the deployment target.
Stick with an existing SMTP relay when it is mandated, already monitored, and easier for the organization to operate than a new API contract. Choose a webhook-capable email provider when downstream automation needs prompt push events. Use a dedicated multi-channel provider when voice, WhatsApp, or RCS is part of the recovery design. And if your team needs to cancel scheduled email, confirm that capability before committing: scheduled email exists here, but email cancellation does not, while SMS cancellation is a separate supported operation.
For the narrow case in the title, the decision remains simple: direct HTTP is the lower-effort architecture, single-send is the right primitive, and message correlation plus event lookup is the operational minimum. The vendor choice comes after those requirements, not before them.
Top comments (0)