An email webhook lets your application react when new information becomes available. It also introduces another network boundary. The receiver may be unavailable, an event may be delivered again, and processing may fail after the request arrives. Design for those possibilities before wiring an event directly to a business action.
Follow the actual event contract
Use Sendar's current webhook documentation to configure the endpoint and understand its payload. Do not copy another provider's signature header, retry policy or event names into your handler and assume they match.
Associate the incoming event with the Sendar message identifier you recorded when sending. This links delivery information to the relevant order or notification without using an email address as the only correlation key.
Persist before doing expensive work
Validate the request according to the documented contract and record the event durably. Keep the synchronous handler small. If processing requires several database changes or calls to another service, move that work behind a durable queue in your application.
Acknowledge only once you have accepted responsibility for the event. Returning success and then losing the payload before storing it creates a gap that is difficult to recover. Conversely, doing too much work before acknowledging can cause unnecessary retries.
Make duplicate processing harmless
Choose a deduplication identity from the documented event fields and store processed events. Do not assume every incoming request represents a new state transition. Where several events describe the same message, preserve the history and avoid letting an older observation overwrite a later confirmed state without a rule.
Do not send a replacement message automatically for every delivery-related event. A webhook should update your understanding of the original send; a new send needs its own authorised reason.
Build a replay path
Keep a bounded record of failed processing with an error reason and attempt count. Test your handler locally using fixtures, including duplicates and an unavailable database. Add a way to replay an event safely after a fix. You want recovery to be a normal operational action, not an improvised script against production records.