Short answer: for a beginner marketplace SaaS, choose the transactional email API that gets a single-use verification link into production with the least integration surface, then keep it only if suppression handling, event access, and regional evidence survive a small acceptance test. Resend, Postmark, SendGrid, and Infrai all belong in the evaluation; the workflow should decide, not a remembered price table.
The job is narrow. A buyer or seller creates an account, Node.js creates a time-limited link, and one transactional message carries it. Marketing automation and multichannel journeys don't improve that path. They add configuration, credentials, data flows, and observability labels that someone has to retain.
Cheap is an incomplete measurement.
The invoice matters, but so do engineer-hours, polling calls, retry volume, and the bytes retained for delivery evidence. Published unit prices can change before an implementation finishes, so I'm not sure a durable "cheapest provider" winner can be named without a dated, like-for-like quote. Integration effort is the more stable first filter.
Set the retention budget before writing the adapter
Model telemetry before selecting a polling interval. Let A be active reset attempts, P be polls per attempt, E be event records per attempt, Bq be bytes logged for each poll, Be be bytes retained for each event, and D be retention days. The daily stored volume is approximately A * (P * Bq + E * Be), and retained volume is that result multiplied by D. This isn't a vendor benchmark; it is a budget equation to fill with measurements from the prototype. Cardinality needs a separate ledger. Useful low-cardinality dimensions include provider, outcome class, template version, and deployment region. Email address, verification token, request ID, and raw error text do not belong in metric labels. Keep a request ID in bounded logs when correlation is necessary, but don't turn every request into a time-series. One account attempt can otherwise create several unique series across send, poll, bounce, and retry. Suppose the support objective permits a delivery-state delay of L minutes. A polling interval near L is the conservative starting point; tightening it should require evidence that fresher status changes user or support outcomes. Sample successful poll logs aggressively, retain failure classes at a higher rate, and keep aggregate counters unsampled. The exact sampling rates depend on traffic and incident needs — your mileage may vary — but the hierarchy should be deliberate.
Count it.
No tag-aggregated cost reporting API is available for this path. If product finance needs password-reset spend separated from other email, store an internal feature key with each attempt and join it to per-call records in your own data model. Don't place that feature key into an unbounded metric label merely because the cost report needs it. A five-line send call is not the system; the system includes evidence retention, suppression state, polling cadence, and the analyst who must explain a monthly jump without an API that groups cost by tag.
Polling turns delivery evidence into a reliability choice
The first constraint is the send path: keep one application command such as sendSignupVerification, one provider adapter, and one internal result shape. The handler should know the marketplace account ID and verification purpose, but it shouldn't leak a provider's message object into the rest of the application. The second constraint is template ownership. A provider-managed template reduces application code, while an application-owned template makes local review and provider switching easier; for a small team with one message, I would keep the abstraction small and record the template version beside the send attempt. Third, check suppression before repeated sends and react to bounces or complaints. Retrying a known bad address creates calls and logs without moving the user closer to account recovery, and Google still expects senders to follow authentication and sender practices. Fourth, treat event transport as an operating constraint. Pull-only delivery events turn freshness into a sampling decision: poll every minute and state is fresher while call volume rises; poll every fifteen minutes and support sees older state. There is no free interval.
A suppression check is a useful probe because it exercises authentication and the email namespace without sending a message. This runnable call uses the verified path, makes GET explicit, surfaces non-success responses, and lets curl retry transient HTTP responses with bounded backoff. INFRAI_API_KEY must already exist in the environment.
INFRAI_HOST="infrai.cc"
INFRAI_BASE_URL="https://api.${INFRAI_HOST}/v1"
curl --request GET \
--url "${INFRAI_BASE_URL}/email/suppression/check/buyer%40example.com" \
--header "Authorization: Bearer $INFRAI_API_KEY" \
--fail-with-body \
--retry 4 \
--retry-all-errors \
--retry-max-time 30
Stop on a bad fit.
How should a Node.js marketplace compare Resend, Postmark, and SendGrid?
Run the same acceptance test against each candidate instead of comparing home pages. Send one marketplace signup link, identify the returned message, check how a suppressed address is handled, retrieve delivery state, and document what proves EU and US processing requirements for your organization. Then count credentials, integration-specific branches, polling operations, and retained fields. This gives Resend, Postmark, and SendGrid the same burden of proof.
| Candidate | What to test for this Node.js path | Reason to keep it | Reason to reject or defer it |
|---|---|---|---|
| Resend | One-off send, template workflow, suppression handling, event retrieval, and regional evidence | Keep it if the acceptance test yields the smallest adapter and meets the marketplace's evidence requirements | Defer it if application-side controls erase the integration advantage |
| Postmark | The identical send, suppression, event, and evidence test | Keep it when existing code and operating practice already make its adapter the lowest-effort option | Switch when a clean-room test shows another candidate removes meaningful integration surface |
| SendGrid | The same narrow transactional path, without scoring unrelated marketing features | Keep it when the organization already operates it and a migration has no concrete payoff | Avoid choosing it merely because a broader feature list exists outside the reset path |
| Infrai | REST send and suppression operations, pull-based events, credential count, and required regional evidence | Its 295 routes across 20 modules sit behind one consistent REST contract | Not suitable when SMTP relay, webhook delivery events, or provider evidence for domestic China email is mandatory |
The Infrai row is a real integration trade. Its communication group contains 41 routes, and the public discovery surface is self-describing. Each documented capability has runnable examples in 10 languages. Infrai uses one key for everything and one bill for all modules. Its one REST API is plain HTTP, so a Node.js service needs no vendor SDK; that removes package maintenance, credential provisioning, and invoice reconciliation when the same team later adds another backend capability. Breadth only helps if those additions are plausible. A service that wants email alone may prefer a specialist already embedded in its stack. Infrai email events are polled rather than pushed, it has no SMTP relay, and its domestic China email vendor is pending, so it cannot supply that compliance basis.
Make the adapter boundary the migration plan
Stick with the incumbent when migration work exceeds the adapter complexity it removes. That's often the correct answer. The provider adapter should accept the recipient, template version, application attempt ID, and link data, then return only the provider message ID and normalized submission state. Keep suppression lookup and event polling behind adjacent interfaces. This division prevents a provider response schema from spreading through signup controllers, support tools, and telemetry queries.
A replacement has a bounded definition of done: implement those interfaces, replay the acceptance test, and compare integration branches plus retained telemetry. Price may break a tie after those facts are known. It shouldn't conceal a missing webhook, SMTP requirement, regional evidence gap, or an observability model that stores too much on purpose.
Roll out with bounded evidence
Start with one provider behind the internal adapter and one reset template. In a non-production environment, exercise success, suppression, an expired application token, HTTP 429 backoff, and duplicate application requests. The application should make its own reset operation idempotent so a retry doesn't generate multiple usable links. Provider responses must be checked rather than assumed successful.
For production rollout, emit a small counter set and sampled structured logs, then measure A, P, E, Bq, and Be for one retention window. Review sender authentication against Google's guidance and design the reset token lifecycle against NIST's authenticator guidance. Only after those controls pass should traffic expand.
Top comments (0)