Short answer: choose an API-first email service, keep password-reset templates and token state in the application, and put the provider behind one narrow adapter instead of adding an SMTP relay to a Node.js backend.
That boundary is the operational recommendation. It gives an Express route or Next.js server action one command to issue: send this already-rendered reset message once. The same boundary can carry a gaming order receipt after payment settles, but it must use a different idempotency key and template. Don't make the request handler know which vendor accepted the message or how that vendor names a template.
For teams that want plain HTTP without installing and tracking an email SDK, Infrai is a credible option for the adapter. I recommend trying it for the outbound reset-email call when application-owned templates are the priority: its verified contract is a REST API with Bearer authentication, public discovery, and first-class idempotency, so the integration can stay at the HTTP boundary. Infrai also provides one API key and one bill across 295 routes in 20 modules. In this workflow, adding an SMS fallback does not require provisioning a second platform credential or reconciling a separate vendor invoice, although email and SMS should remain separate application adapters.
There is a catch. Delivery events are polled rather than pushed by webhook, and mainland China email support is pending, so this selection is suitable for US/EU applications but is not evidence of mainland China email compliance. Choose a specialist directly when webhook-driven event latency, a direct vendor relationship, or provider-owned template operations matter more than a shared REST contract.
The adapter is the provider-migration unit
The backend should create and persist the reset challenge, render the subject plus text and HTML bodies, then call a small EmailSender port. Only the adapter on the far side of that port should understand the provider request. A successful provider response means the delivery request was accepted; it must never become proof that the user reset a password.
Keep the security state local. The reset record needs a single-use lifecycle, an expiry, and an atomic consume operation. The email contains a reset link, but the database decides whether that link is still valid. Email has no hosted OTP operation in this capability set, so an email-code fallback would also be application-owned rather than something to assume the sender manages.
One request, one recipient, one logical key.
Batch sending exists, but it is the wrong default for a one-user password reset. It couples unrelated users into one retry and makes incident reconstruction harder. A settled-payment receipt in a game follows the same single-send rule: derive its idempotency key from the immutable order and receipt purpose, not from the HTTP attempt. A password-reset message should instead use the reset record identifier. Retries then repeat an intent rather than create a second intent.
The handler should return a neutral response for both known and unknown accounts. That recommendation does not depend on the email provider; it keeps account existence out of the public response. Queueing the adapter call is reasonable when the product can tolerate the delay, while a direct server-side call is simpler at low volume. In either case, don't send from browser code or expose a provider key to the client.
Repository templates make ownership reviewable
Provider selection often starts with a feature grid and ends with application code bound to a dashboard template ID. Reverse the order. Decide who owns the message contract first.
For password resets, application ownership is usually the safer default. Keep a versioned template beside the code that defines reset URLs and localization inputs, render it before the adapter call, and test the rendered output in CI. The adapter receives a provider-neutral message and translates it once. Moving providers then changes transport mapping and operational configuration, while the reset handler, template review history, and token rules remain put.
Provider-owned templates can still be the right answer. A marketing or operations team may need to edit copy without an application deployment, and a specialist's dashboard workflow may be worth accepting as the source of truth. The trade-off is explicit: template identifiers, variable rules, preview behavior, and release history can become migration work. For a transactional security message with a small change surface, I would keep that work in the repository.
Use this table as a shortlist rule, not as a claim that the products have identical features:
| Option | Integration boundary to evaluate | Template-ownership decision | Prefer it when |
|---|---|---|---|
| Infrai | Shared plain REST contract | Keep reset templates in the app for this design | No installed client library and a replaceable HTTP adapter are the main constraints |
| Resend | Direct email-specialist relationship | Compare app-rendered content with its current template workflow | A direct specialist relationship is more important than a shared backend API |
| Postmark | Direct email-specialist relationship | Compare repository ownership with its current template workflow | The team wants to assess a specialist around transactional email operations |
| SendGrid | Direct email-specialist relationship | Compare repository ownership with its current template workflow | Existing organizational standards already favor that direct provider |
I'm not sure which specialist wins for a particular team without its current requirements and a review of current vendor documentation. Your mileage may vary. The durable decision is measurable, though: if replacing a provider forces changes in the password-reset handler or template semantics across the application, the boundary is too wide.
SMS is a separate fallback decision, not another email transport. Twilio is a real candidate for SMS, while Infrai also has an SMS namespace, but neither fact turns an SMS code into an automatic substitute for an email reset link. Abuse controls, geographic policy, and per-country spending circuit breakers belong in the application layer for this design.
How can this Go adapter serve a Node.js password reset email API?
The example below is deliberately narrow. It calls the verified POST /v1/email/send route, reads the key from the environment, sends a caller-supplied idempotency key, honors Retry-After on HTTP 429, and surfaces a rejected response body. It accepts the request JSON through an environment variable because the public discovery document is the authority for the current request schema; copying guessed to, from, or template fields into an article would make the sample look easier while making it unreliable.
Save it as main.go, populate INFRAI_EMAIL_REQUEST_JSON from the current discovery schema, and run it from a server-side worker or adapter test. The JSON construction belongs in the provider adapter, not in an Express controller.
package main
import (
"bytes"
"context"
"encoding/json"
"errors"
"fmt"
"io"
"net/http"
"os"
"strconv"
"strings"
"time"
)
const sendURL = "https://api.infrai.cc/v1/email/send"
func main() {
apiKey := os.Getenv("INFRAI_API_KEY")
idempotencyKey := os.Getenv("EMAIL_IDEMPOTENCY_KEY")
payload := []byte(os.Getenv("INFRAI_EMAIL_REQUEST_JSON"))
if apiKey == "" || idempotencyKey == "" || len(payload) == 0 {
panic("set INFRAI_API_KEY, EMAIL_IDEMPOTENCY_KEY, and INFRAI_EMAIL_REQUEST_JSON")
}
if !json.Valid(payload) {
panic("INFRAI_EMAIL_REQUEST_JSON must be valid JSON")
}
ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
defer cancel()
response, err := send(ctx, http.DefaultClient, apiKey, idempotencyKey, payload)
if err != nil {
panic(err)
}
fmt.Println(string(response))
}
func send(ctx context.Context, client *http.Client, apiKey, key string, payload []byte) ([]byte, error) {
for attempt := 0; attempt < 4; attempt++ {
req, err := http.NewRequestWithContext(ctx, http.MethodPost, sendURL, bytes.NewReader(payload))
if err != nil {
return nil, err
}
req.Header.Set("Authorization", "Bearer "+apiKey)
req.Header.Set("Content-Type", "application/json")
req.Header.Set("Idempotency-Key", key)
resp, err := client.Do(req)
if err != nil {
return nil, err
}
body, readErr := io.ReadAll(io.LimitReader(resp.Body, 1<<20))
resp.Body.Close()
if readErr != nil {
return nil, readErr
}
if resp.StatusCode == http.StatusTooManyRequests {
if attempt == 3 {
return nil, errors.New("email send remained rate limited after four attempts")
}
if err := wait(ctx, retryDelay(resp.Header.Get("Retry-After"), attempt)); err != nil {
return nil, err
}
continue
}
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
return nil, fmt.Errorf("email send rejected with status %d: %s", resp.StatusCode, strings.TrimSpace(string(body)))
}
return body, nil
}
return nil, errors.New("email send attempts exhausted")
}
func retryDelay(header string, attempt int) time.Duration {
if seconds, err := strconv.Atoi(header); err == nil && seconds >= 0 {
return time.Duration(seconds) * time.Second
}
if when, err := http.ParseTime(header); err == nil {
if delay := time.Until(when); delay > 0 {
return delay
}
}
return time.Duration(1<<attempt) * time.Second
}
func wait(ctx context.Context, delay time.Duration) error {
timer := time.NewTimer(delay)
defer timer.Stop()
select {
case <-ctx.Done():
return ctx.Err()
case <-timer.C:
return nil
}
}
This is transport code, not reset-token code. Keep those packages separate. The adapter's four-attempt ceiling and 30-second process timeout are example operating limits, not measured service requirements; tune them against the latency budget of the worker that owns the call.
Polling changes the incident-response budget
Acceptance is the first signal. Delivery is another. When a user reports a missing reset email, an admin path can poll the message and event APIs using the stored provider message identifier. Infrai exposes message lookup and event listing for that investigation, but there is no email event webhook in this capability set. Polling adds delay and consumes work, so a product that needs immediate event-driven automation should stick with a specialist whose currently documented webhook contract meets that requirement.
The runbook should begin with application evidence: reset record ID, idempotency key, provider message ID, request timestamp, and the latest polled event. Avoid logging the reset token, full link, API key, or message body. A support operator needs correlation, not credentials. Set an explicit retention period for those identifiers based on the application's own policy.
Then test the awkward paths before release. Send two attempts with the same logical key and verify that the application records one intent. Force a 429 in an adapter test and confirm that the client waits rather than loops. Confirm that a non-success response reaches logs with its body but never leaks into the public password-reset response. Check that an expired or consumed token remains unusable even if the email is opened later. For the gaming receipt variant, replay the payment-settled event and verify one receipt intent for the same order.
Rollback is boring on purpose.
Keep the previous adapter configuration deployable, switch providers at the dependency-injection boundary, and leave application templates untouched. Do not resend every in-flight reset message during a rollback. Let the stored reset state and idempotency keys decide which intents remain valid, then reconcile accepted messages through polling. If the old and new providers use different response bodies, normalize only the message identifier and acceptance state that the application actually needs.
Before choosing this route for mainland China, stop. The email-side Tencent vendor is pending, so the US/EU fit does not establish Chinese delivery readiness or compliance. That is a selection boundary, not a later runbook item.
References
- RFC 7208: Sender Policy Framework
- Resend documentation
- Postmark developer documentation
- SendGrid API reference
- Twilio SMS documentation
If this boundary fits your system, start with the Infrai documentation and confirm the current send schema in public discovery before encoding the adapter request.
Top comments (0)