A password-reset email should be tied to a real reset request for the right customer. This example gives your existing Next.js application a callback that verifies that event, plus a server helper that prepares and validates the email before a separate reviewed send. The download includes source code, a database lookup you can adapt, and tests you can run locally.
Start with the downloadable example
Download the ZIP from Sources and next steps below. It includes a complete Next.js project, pinned dependencies, the callback route, a read-only SQLite event lookup, server helpers, a sample database schema and a README. Use Node.js 22.18 or later and pnpm 11.19.0.
After extracting the project, run pnpm install --frozen-lockfile, pnpm test, pnpm build and pnpm test:http. Start the local preview with pnpm dev. Without your event database and shared secret, the health endpoint reports unavailable and events cannot be approved. The test runner creates and removes its own synthetic database.
Keep your application's password-reset workflow in charge
Your application still owns the reset request, customer identity, token generation, expiry, single-use redemption and password change. The example does not replace your authentication system or create a public endpoint that can send arbitrary email.
Connect the lookup to your existing customer and reset-event records. The callback requires an active customer, an unchanged customer email, an unrevoked event and the stored event timestamp. It also compares the exact recipient, template ID, approved template version and expected content fingerprint. Missing or mismatched records are rejected.
Bind the event to the email you actually intend to send
Before requesting email authorization, your trusted reset workflow must persist the event's expected email binding. Compute that binding from the approved template version and your trusted renderer's exact sender, recipient, subject, text, HTML and reset-URL variable. The included helper covers one password-reset template email without extra recipients, attachments, custom headers or a schedule.
The callback's incoming fingerprint is a value to compare, not a value to save as proof. Never approve an event by copying incoming fields into your event database. If your renderer cannot reproduce the current approved template, resolve that integration first. A new template version needs a new reviewed binding.
Connect, prepare, review and submit
In Emailer API setup, verify your sending domain, install the approved password.reset template and connect your application's HTTPS callback. Store the connection's shared secret and your sending key in server secret storage. Keep them out of browser code and NEXT_PUBLIC environment values.
Call prepareResetEmail from your real server workflow after storing the event. It requests event verification and checks email readiness without sending. Review and save the exact returned payload through your application's existing approval step, then call sendReviewedReset. Retry uncertain acceptance using that same payload and event ID as the idempotency key.
An accepted or queued email is not proof of delivery. Check Email Logs or your configured delivery webhooks for the reported outcome. This example does not send a test message to a real mailbox.
What the verification established
Nine automated tests passed for this release. They cover stored-event success, authenticated responses, changed identity and content bindings, inactive or changed customers, revoked and expired events, invalid signatures, malformed bodies, streaming body limits, unavailable databases, and separate preparation and sending.
The production Next.js build passed. An HTTP check then started that built application on a local port, verified its routes and headers, approved a synthetic stored event and rejected an inactive synthetic customer. Six content-fingerprint comparisons matched the actual Emailer API implementation; the checked source hashes matched the live API release on September 8, 2026.
These checks establish the example's behavior under those conditions. They do not establish a production SMTP delivery, successful password redemption in your application, customer activation or improved business results.
Deploy the lookup that fits your application
The included SQLite adapter opens an existing database read-only and needs a persistent Node.js filesystem. For an application using PostgreSQL or another shared store, adapt the lookup to that store. Do not use the SQLite adapter on an Edge runtime or assume an ephemeral filesystem can share events across instances.
Serve the callback over HTTPS, enforce a 16 KiB body limit and a request timeout at your proxy, and apply an appropriate callback rate limit. Keep your application's existing authentication, CSRF and abuse controls on reset requests and review actions. Preserve event IDs and send receipts when rolling back an application release; a rollback is not a reason to resend an uncertain message.
Continue with a related guide
Sources and next steps
- Download the tested Next.js example (ZIP, version 1.0.0)
- Emailer API documentation
- Next.js Route Handlers
- Next.js deployment options
Start free with setup help included · Read current plan limits
Reviewed by the Emailer API editorial assistant against the linked documentation. Version 1.0.0 passed nine automated tests, a production Next.js build, local HTTP checks and six comparisons with the live API's content-digest implementation. Synthetic records only; no production email was sent.