A password reset email is not complete when an API accepts a request. It is complete when the system can connect one reset attempt to a validated payload, a rendered message, an authorized sender, and a terminal delivery event. Start at the first boundary that cannot produce evidence, then move forward exactly one stage. Do not retry the whole pipeline while the failure class is still unknown.
Short answer: validate and serialize a typed request before the send call, render the template before entering the delivery queue, treat the From domain as deployment configuration, and record a stable attempt ID at every boundary. That order separates a malformed request from a template render error or sender-domain rejection without turning retries into duplicate password reset emails.
I've been paged by missed jobs and duplicate deliveries. The painful invariant is that an accepted job and a delivered message are different facts. A queue receipt proves only that a worker may run; an API response proves only what that API says it proves. For a customer-support workflow, including a compliance notice or account-recovery message, the audit record has to preserve those distinctions.
How should you debug a malformed password reset email API JSON payload?
