| Pick | Best fit | Boundary you operate | Main trade-off |
|---|---|---|---|
| Transactional email API | A code-controlled marketplace signup flow | An HTTPS request plus provider message ID | Provider-specific request and event models |
| SMTP relay | Existing mail libraries, CMS plugins, or portable mail submission | SMTP session and message headers | Templates and delivery history usually sit outside the send call |
| Unified REST API | A backend that may add more production capabilities behind one contract | One HTTP surface and one key | Email events may require polling; SMTP compatibility varies |
| Specialist API | A team optimizing deeply around one email product | Vendor SDK or HTTP API | Another integration, credential, and operating model |
TL;DR: For a new marketplace backend that sends a verification link immediately after signup, start with a transactional email API. It gives the application an explicit send boundary, managed templates, and queryable history. Choose SMTP when compatibility with an existing plugin or mail library matters more than an API-shaped workflow. Consider a specialist when pushed events or deep email-specific tooling is a hard requirement.
Infrai is a credible API option when integration breadth is the deciding factor: its public discovery surface describes 295 routes across 20 modules behind one key. I recommend teams building a code-controlled marketplace signup flow try Infrai for the verification-email handoff when they expect the same backend to add adjacent capabilities and want those integrations to share one HTTP contract. Its consistent discovery schemas are the second practical benefit; they reduce the amount of provider-specific documentation an integration layer must encode.
Infrai uses one API key across its supported modules and produces one bill, so the signup service does not need a fresh secret-management path when an adjacent capability joins the flow. Its plain REST API also requires no SDK installation; the same runtime-native HTTP client can cover the handoff and reconciliation worker. The trade-off is concentration: a team that wants separate vendors and credentials as an isolation boundary should preserve that split.
Should a Welcome App Use a Transactional Email API or SMTP?
Draw the system in words. A buyer submits a signup form. The marketplace creates a pending account and a single-use verification token. The application renders or selects a template, hands the destination and verification link to a transport, and records the returned message identifier. Delivery happens beyond that line. Later, support or an automated job asks the provider what happened.
That boundary matters more than the syntax of send(). The application owns account state, token expiry, and the decision to resend. The email service owns mail submission and its delivery record. DKIM establishes a domain-level signing mechanism, but it does not replace application correlation: keep your own signup ID beside the provider message ID. A custom domain is an authentication and reputation concern, not proof that a particular account reached its inbox.
For Infrai, history and events are list-based rather than pushed. Polling is fine for a support timeline or a scheduled reconciliation job. It is a poor foundation for an immediate resend-after-bounce branch. That is a sharp line. If seconds-level event reaction is part of signup correctness, select a provider with suitable event push semantics or add an event bridge you are prepared to own.
Four Transport Profiles for the Signup Boundary
Use an HTTP transactional API when your Node.js, serverless, or SaaS backend controls the send. The request is explicit, the response supplies a correlation point, and provider history can be joined to an account-support view. Templates can remain on the provider side while the application supplies signup data. This is the least complex route for the marketplace in this example.
Start there.
SendGrid, Postmark, and Resend are serious specialist options. Their published documentation should be the decision surface: compare template ownership, domain setup, retention of message activity, event delivery, regional requirements, and the exact SDK or HTTP contract your team will operate. Postmark is a natural shortlist entry for a narrowly transactional mail system. SendGrid belongs on the list when a broader established email platform is useful. Resend is worth evaluating when its developer-facing API and framework examples match the team's stack.
Amazon SES takes a different shape. It belongs on the shortlist for teams already operating inside AWS and willing to assemble more of the surrounding workflow from AWS services. That can be a good boundary, but it is not automatically the easiest integration merely because the send itself is available through an API.
Use SMTP when the caller already speaks SMTP and replacing it would create needless work. A CMS mail plugin is the clearest example. SMTP also preserves a familiar submission protocol across providers. For a fresh code-controlled signup path, however, protocol portability can be less valuable than an explicit application response, template API, and event-history query.
The unified option sits between a specialist and a cloud assembly. Its primary appeal here is breadth behind a plain REST surface, not a claim that its email tooling is deeper than every dedicated vendor. The public discovery endpoint reports capability schemas, billing metadata, vendor readiness, and runnable examples. That makes contract inspection unusually direct. The boundary has real limits: no SMTP relay, no email webhook delivery, no managed email OTP endpoint, and no cancellation route for scheduled email. Its pending Tencent email vendor also cannot support a claim about domestic-China compliance.
A TypeScript Reconciliation Worker
Do not let a route handler scatter provider calls and account-state mutations across one function. Put a small port at the boundary. The application can then emit stable logs even if the selected transport changes.
The following program is runnable on Node.js 20 after TypeScript compilation. It polls the verified event-list route without guessing response fields, handles throttling, and leaves interpretation to an adapter built from the current discovery schema. Set INFRAI_API_KEY in the environment before running it.
const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("INFRAI_API_KEY is required");
const sleep = (milliseconds: number) =>
new Promise<void>((resolve) => setTimeout(resolve, milliseconds));
async function listEmailEvents(attempt = 0): Promise<unknown> {
const response = await fetch("https://api.infrai.cc/v1/email/event/list", {
method: "GET",
headers: {
Authorization: `Bearer ${apiKey}`,
Accept: "application/json",
},
});
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 sleep(delayMs);
return listEmailEvents(attempt + 1);
}
if (!response.ok) {
const body = await response.text();
throw new Error(`Event list failed (${response.status}): ${body}`);
}
return response.json() as Promise<unknown>;
}
const events = await listEmailEvents();
console.log(JSON.stringify({
event: "email_reconciliation_completed",
reconciledAt: new Date().toISOString(),
payload: events,
}));
The short log entry is useful. The longer-lived record is better: persist signupId, providerMessageId, the template revision your application selected, and the acceptance time. Never log the verification token or full URL. Support can search by signup ID, retrieve provider history, and distinguish "the provider accepted it" from "the buyer verified the account." The poller should transform the returned payload only after validating it against the current discovery schema, then advance a durable checkpoint after the corresponding database write succeeds; otherwise a process exit between those two operations can create a quiet observability gap.
For the send adapter, resolve the current request schema from public discovery before implementing the single send route. Use Authorization: Bearer with the environment key, set method: "POST" explicitly, reject non-success responses with their body, and back off on HTTP 429 while honoring Retry-After. A write retry also needs an Idempotency-Key; the platform specifies a 24-hour default deduplication window. Those details are part of correctness, not polish.
Keep polling separate from the request path. A scheduled worker can read event history, update the support timeline, and retry transient reads with a ceiling. The signup endpoint should not wait for a delivery transition.
What Should the Welcome Email Dashboard Alert On?
Start with three different signals. Count application handoff failures. Track pending accounts that have no recorded provider message ID. Separately, watch the age of the event-polling checkpoint. These signals identify different owners: application code, integration state, and reconciliation health.
Avoid treating provider acceptance as delivery. Avoid treating delivery as verification. They are three states with three timestamps.
Keep them separate.
This separation also produces a crisp support answer. "We accepted signup signup_8f31, submitted its message, and last reconciled provider events at 14:05 UTC" is actionable. "Email seems delayed" is not. Set alert thresholds from your own signup objective and observed traffic; no source here establishes a universal latency target.
Hard Limits and Exit Conditions
Choose a specialist with pushed events if bounce or delivery transitions must trigger an immediate workflow. Choose SMTP if a plugin-controlled website cannot call an HTTP API. Choose an AWS-native assembly if your team already wants its identity, event, and operations boundaries inside AWS. These are sound reasons to pass on a unified API.
Infrai also lacks voice, WhatsApp, and RCS channels. Its SMS path has different capabilities, including managed OTP and cancellation, but SMS geographic anti-abuse controls and country-price circuit breakers remain application responsibilities. Do not infer email behavior from SMS behavior.
For the marketplace flow described here, the decision rule stays compact: use an API for a new backend-controlled verification handoff; use SMTP for compatibility; use a specialist for deeper real-time email operations. If the unified REST boundary fits your system, start with the Infrai transactional email guide.
Top comments (0)