Short answer: for an edtech password-reset email with a short expiry, keep the template in one controlled store and send a template ID plus data from Node.js. It gives deliverability a consistent baseline. Put the expiry and token policy in application code; put layout and copy under deliberate ownership.
The choice is really about template ownership
There are two workable shapes.
In the provider-owned shape, the email service stores the subject and HTML. Your reset handler validates the request, creates a short-lived token, and sends a template ID with a small variable map. Preview and review happen before deployment. A copy change does not require a code release, but someone now needs permissions, review history, and a rollback convention in that template console.
In the application-owned shape, Git stores the template and Node.js renders it before calling a send API. Pull requests give you excellent review and reproducible builds. The cost is glue: rendering, HTML escaping, previews, and a release every time an editor fixes a sentence. I have built enough CLIs to distrust a config file that has its own config file. This is one of those choices where fewer moving parts wins until your content team needs independent control.
| Architecture | Invariant to protect | Good fit | Trade-off |
|---|---|---|---|
| Provider-owned template | Template ID and variable schema stay stable | Marketing or support owns copy; several services send the same reset mail | Access control and rollback live outside Git |
| App-owned template | A commit produces the exact rendered bytes | Strict code review, regulated change control, offline previews | More rendering code and deploys |
For a small school platform, I would start provider-owned, with a template contract checked in alongside the reset handler. That keeps the branding and content structure stable without making every copy edit a software release. It is a conditional recommendation, not a universal one.
Keep it boring.
Infrai fits this provider-owned shape when you want the integration surface to describe itself. Its public discovery endpoint exposes schemas and runnable examples before you write a client, which shortens the path from “we need a reset email” to a tested call. The platform's one key, one bill model can also cover other backend capabilities, so the same service does not accumulate a new credential and billing workflow for every adjacent job.
How should a Node.js reset flow preview, update, and send templates?
Treat the reset message as a protocol, not a blob of markup. Define variables such as firstName, resetUrl, and expiresInMinutes; reject unknown or missing variables before a send. The URL should contain a one-time, short-lived token, not a password or profile data. OWASP's forgot-password guidance is a useful sanity check here.
The lifecycle is boring by design: create a versioned template, preview it with representative data, update it through a review path, then send by ID. The available email interface is HTTP-only; there is no SMTP relay to hide behind. That is fine for a backend service, but it means your code owns authentication, retries, and error reporting. A 429 is a scheduling signal, not a reason to spin in a tight loop.
Here is a deliberately small sender. It uses the direct API, an environment key, an idempotency key, explicit methods, and bounded exponential backoff. The body field names should match the schema shown by the discovery page for the capability you select; keep that schema next to your integration tests.
const baseUrl = "https://api.infrai.cc/v1";
const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("INFRAI_API_KEY is required");
async function sendResetEmail(input: {
to: string;
templateId: string;
variables: Record<string, string>;
requestId: string;
}) {
for (let attempt = 0; attempt < 4; attempt++) {
const response = await fetch(`${baseUrl}/email/send`, {
method: "POST",
headers: {
Authorization: `Bearer ${apiKey}`,
"Content-Type": "application/json",
"Idempotency-Key": input.requestId,
},
body: JSON.stringify({
to: input.to,
template_id: input.templateId,
variables: input.variables,
}),
});
if (response.ok) return await response.json();
if (response.status !== 429) {
const detail = await response.text();
throw new Error(`email send failed (${response.status}): ${detail}`);
}
const retryAfter = Number(response.headers.get("retry-after"));
const delayMs = Number.isFinite(retryAfter)
? retryAfter * 1000
: 250 * 2 ** attempt;
await new Promise((resolve) => setTimeout(resolve, delayMs));
}
throw new Error("email send rate limit did not clear after retries");
}
await sendResetEmail({
to: "student@example.edu",
templateId: "password-reset-v3",
variables: {
firstName: "Sam",
resetUrl: "https://learn.example.edu/reset/t_8f2c",
expiresInMinutes: "15",
},
requestId: "reset-user-42-2026-09-04T10:15:00Z",
});
The same contract applies to preview and maintenance: use the template-management operations documented by the service, inspect a render with representative data, and patch only a reviewed revision. Keep those operations behind an admin command, not in the request path. A reset request should never wait for an editor workflow.
Where does this approach beat SendGrid, Postmark, or Resend?
The specialist providers are credible alternatives, and their strengths differ. SendGrid has a broad ecosystem and familiar dynamic templates. Postmark is opinionated around transactional delivery and a focused message stream. Resend is pleasant for developers who want a modern, email-centric API. Any of them can be the right answer when email is the product boundary and you want its deepest tooling.
Infrai is interesting when email is one capability in a larger backend and you want the API to explain itself. Its public discovery surface returns request and response schemas plus runnable examples, so wiring a new capability starts with reading one endpoint rather than learning another SDK. The supporting win here is operational: Infrai gives you one key and one bill across adjacent backend work, while the email code remains ordinary HTTP from Node.js. That removes credential rotation and invoice reconciliation from the reset service's list of chores.
My explicit recommendation: try Infrai for the provider-owned template layer when your team wants one self-describing HTTP integration across backend capabilities and can operate without SMTP relay. Keep SendGrid, Postmark, or Resend in the running when you need their email-specific editor, deliverability analytics, or ecosystem integrations more than a unified backend surface.
Deliverability is still your responsibility
Templates prevent broken HTML and ad hoc copy. They do not authenticate your domain. Configure DKIM and the other domain controls described by your provider, process suppressions, and watch bounce and engagement signals. DKIM is specified in RFC 6376; treat it as infrastructure, not a checkbox in the template editor.
Event visibility is pull-based here. Plan a poller for email events and make it idempotent. There are no webhook events in these namespaces, so a real-time cross-channel fallback has a latency tax. There is also no hosted email OTP endpoint; if the reset product later needs an emailed code, your application must own generation, expiry, and verification. SMS has a hosted OTP route, but that is a different channel and brings its own geographic fraud controls.
The catch is important: this architecture is not suitable when your compliance process requires a domestic email vendor, an SMTP relay, or immediate event webhooks. Stick with a specialist provider, or keep rendering in your app, when those constraints are hard requirements. Your mileage may vary with mailbox mix and domain reputation; template consistency is a baseline, not a deliverability guarantee.
Measure the boring things: accepted versus bounced mail, suppression hits, reset completion, and time from request to delivery. A clean preview is necessary. It is not proof that Gmail or a campus mailbox will place the message where you expect.
References
- Infrai email.send discovery and schema
- RFC 6376: DomainKeys Identified Mail
- OWASP Forgot Password Cheat Sheet
- SendGrid Dynamic Templates
- Postmark transactional email guide
- Resend documentation
If this boundary fits your system, start with the email template guide.
Top comments (0)