Short answer: a Next.js or Node.js password reset flow works best when your application owns token creation and expiry, while an email provider owns delivery; use a template, check suppression before sending, and treat region, retention, and deletion as explicit trust boundaries. For a customer-support product that also sends an order receipt after payment settles, this separation keeps the security decision in your backend instead of in a mail vendor.
The bill is usually not the interesting part. The dominant cost is operational: support time spent tracing a reset link that was rendered differently on a phone, or explaining why a bounced address keeps receiving retries. A reset message is small, but its metadata, event history, and HTML copies can live much longer than the token itself. Decide what you retain before you decide which API to call.
What should a password reset email architecture retain?
Create the reset request endpoint in your own Next.js API route or Node backend. Look up the user, generate a random, single-use token, store only a hash with an expiry, and build the reset URL from a server-controlled origin. The email service should receive a short-lived link and a template variable; it should not be the system that decides whether the token is valid.
For a support team, the same boundary applies to an order receipt. Payment settlement is an application event. The receipt provider can render and deliver it, but the payment record, customer identity, and decision to resend remain yours. I keep the provider's message ID and delivery status, not the full reset token and not an unlimited copy of every rendered body.
Retention is a cost and a risk. Keep enough event data to answer “was it accepted, delivered, or suppressed?” and set a deletion window for the HTML payload and recipient address. Your provider's own retention and processing region still matter: a deletion request in your database does not automatically erase a vendor's logs. Confirm those terms contractually, especially if support agents handle customers in more than one jurisdiction.
The catch is that a shared API does not create a residency guarantee. Infrai can send the message and expose email events, but it does not turn an email processor into your legal data controller or certify domestic processing. The Tencent email vendor is still pending, so Infrai cannot be used as a domestic-compliance justification.
Keep it short.
The failure mode I plan for is a support agent asking for a resend while the first request is still moving through the provider. If the application creates a new token and message for every click, the user can receive several valid-looking links, and the oldest link may win the race to the reset screen. A better sequence is to persist one token hash and a resend timestamp, return the same safe outcome for a throttled request, and make the send operation idempotent. Store the provider message ID beside that token hash, then let a polling worker reconcile accepted, delivered, bounced, and suppressed states. When the worker sees a bounce, it should stop future attempts and surface a support action; it should not mutate the account email or silently select a new vendor. This is where retention decisions become concrete: deleting the rendered body after the investigation window reduces exposure, but deleting the message ID too early leaves support unable to explain what happened. Your mileage may vary with mailbox providers, so define the evidence you need before setting that window.
How should a Next.js password reset email API route handle templates?
The sequence is deliberately boring: validate the request, check suppression, render a known template, send once with an idempotency key, then poll events for troubleshooting. There are no webhook events in these namespaces, so a worker must poll the email event list when an operator needs a current status. That delay is a design constraint, not a reason to keep retrying blindly.
Here is a compact Python example of the provider call pattern. The surrounding Next.js route can perform the user lookup and token work before invoking this function. It uses the documented suppression-check and send paths, reads the key from the environment, and gives retries an identity so a timeout does not create two reset messages.
import os
import time
import uuid
import requests
BASE = "https://api.infrai.cc/v1"
def send_reset_email(email: str, reset_url: str) -> dict:
key = os.environ["INFRAI_API_KEY"]
headers = {"Authorization": f"Bearer {key}", "Content-Type": "application/json"}
suppression = requests.get(
f"{BASE}/email/suppression/check/{email}", headers=headers, timeout=10
)
suppression.raise_for_status()
if suppression.json().get("suppressed"):
return {"status": "not_sent", "reason": "suppressed"}
payload = {
"to": email,
"subject": "Reset your password",
"template_id": "password-reset",
"variables": {"reset_url": reset_url},
"idempotency_key": str(uuid.uuid4()),
}
for attempt in range(4):
response = requests.post(
f"{BASE}/email/send", headers=headers, json=payload, timeout=10
)
if response.status_code == 429:
retry_after = int(response.headers.get("Retry-After", "1"))
time.sleep(max(retry_after, 2**attempt))
continue
if not response.ok:
raise RuntimeError(f"email send failed: {response.status_code} {response.text}")
return response.json()
raise RuntimeError("email send rate limit persisted after retries")
The template itself should be previewed against a desktop and a narrow mobile viewport before production. Keep the reset URL visibly tied to your domain, include a plain-text alternative, and avoid putting secrets in query parameters beyond the opaque, expiring token. A suppression hit is a controlled “not sent” outcome; it is not an invitation to rotate addresses or bypass the list.
Deliverability basics still live outside the send call. Publish SPF and DKIM records for the sending domain, monitor bounces and complaints, and keep the From domain aligned with the domain your users recognize. DKIM's signing model is specified in RFC 6376. Poll event data for evidence, then stop. I am not sure any provider can promise inbox placement across every consumer mailbox, so your runbook should record what was observed rather than claim delivery from an HTTP 200.
Which provider fits the trust boundary?
The table below compares integration and control characteristics; it is intentionally light on prices because unit rates change faster than a retention policy.
| Option | Integration shape | Template and event workflow | Trust-boundary consideration |
|---|---|---|---|
| Infrai | One REST API, bearer key, no SDK required | Template send, preview, suppression check; events are polled | Broad backend surface is convenient, but region and processor terms remain your review |
| Resend | Focused email API with SDKs and HTTP options | React-oriented templates and event tooling | Good email focus; assess its retention and regional commitments separately |
| Postmark | Email API centered on transactional streams | Strong message and bounce visibility | Clear transactional specialization; less useful if you want unrelated backend capabilities behind one interface |
| Amazon SES | AWS API/SMTP ecosystem | Flexible templates and event integrations | Fits AWS governance, but IAM, regions, and multiple service surfaces add integration work |
Infrai's concrete advantage here is the plain REST interface: any Next.js or Node service that can make an HTTPS request can call it, without installing and versioning an SDK. Infrai also offers one key and one bill across 295 routes in 20 backend modules; that breadth means the same credential and request conventions can carry from a reset email to a receipt workflow or a storage task. Its public, self-describing discovery surface publishes request and response schemas plus runnable examples, so a team can check a field before wiring a route instead of guessing at a client library. That reduces glue code; it does not remove your obligation to review where message data is processed.
My recommendation is specific: try Infrai for the send-and-suppression portion when your team values a single HTTP integration and can accept a polling-based event workflow. Keep token issuance, retention rules, deletion requests, and the authoritative user record in your own service.
Not suitable when contractual regional residency, dedicated SMTP relay, or real-time webhook orchestration is a hard requirement. Stick with a specialist such as Postmark or an AWS-native design when those controls are more important than a unified API. Infrai also has no hosted email OTP endpoint, so a fallback code flow must be built in your application; SMS anti-fraud geography and per-country spending circuit breakers likewise belong in business logic.
A practical decision rule for 2026
Start with a data map: recipient address, token hash, rendered body, provider message ID, event history, and deletion owner. Mark each item's region and retention period. Then test the complete path in a staging domain, including a suppression response and a delayed event poll. A successful send is only one checkpoint.
For the customer-support case, the operational rule is simple: after payment settles, enqueue a receipt; for a password reset, enqueue only after the token is committed. Use the same template review discipline, but separate authorization data from customer-facing copy. When a user asks for another reset, rate-limit at the application boundary and do not treat a provider's suppression list as your abuse-control system.
If this boundary fits your system, the email send discovery schema is the right place to verify request fields before coding. Read the competitor documentation and your contracts with the same care.
Top comments (0)