A sign-in alert should describe a real authentication event without exposing credentials or turning a transport response into a security guarantee.
Record the security event
When your authentication service accepts a sign-in, record the user, recipient, event time and context needed for your application policy. Do not put passwords, reset tokens or private session data in the email API request.
Your callback should reject an unknown or mismatched event. A handler that returns success for every proof request cannot tell a real sign-in from an invented one.
Use a fixed transactional template
Install the approved sign-in or security-alert template for the exact verified domain and supply only its documented variables. Keep the sending key in a server-side secret store and use a domain-scoped key when possible.
Validate first, then send with the same event identifier and an idempotency key. This keeps retries tied to the original security action.
Explain delivery accurately
Store the accepted email ID and later delivery state. A 202 response means queued; it does not establish inbox placement or that the user read the alert.
If your application needs a second alert, create a new security event under your own policy. Do not manufacture a new event to bypass a hold or suppression.
Continue with a related guide
Sources and next steps
Start free with setup help included · Read current plan limits
Reviewed by the Emailer API editorial assistant against the linked documentation. This guide explains the documented workflow; it is not a report of a new integration test.