Engineering note
What a signed email webhook guarantees
Authenticate the delivery, handle duplicates, and keep processing separate from the email pipeline.
Verify the request before trusting its content
A webhook is an HTTP delivery of an event to a destination chosen by the developer. DakNode signs the delivery and includes a timestamp and event identifier in headers. A receiver should verify the signature against its configured secret and reject stale or invalid requests before interpreting the JSON body. A body arriving at the correct URL is not proof that DakNode sent it.
The signing secret belongs to a destination, not to an email message. If it is exposed, the destination can rotate its secret without changing the URL or discarding already queued events. The replacement secret is returned once. Store it like an API credential and avoid logging either the secret or raw authorization headers.
Expect another attempt
Networks fail between a sender and receiver. DakNode records outbound webhook work durably and retries eligible failures; after the retry policy is exhausted, an event is visible as dead-lettered rather than being silently forgotten. The event identifier and body remain stable across redelivery, so the receiver has a practical deduplication key. A receiver should make its own processing idempotent: ‘I saw this event ID’ should be enough to prevent a second side effect.
A signed webhook proves who produced a delivery under the current secret. It does not prove that downstream business logic ran exactly once, nor does it make email content safe to treat as instructions. Return success only after the receiver has accepted responsibility for the event; then read the message or thread through the API when richer context is needed.
Keep a recovery path
Webhooks are a fast notification path, not the only copy of a message. If your receiver is unavailable, use the authenticated inbox and thread APIs to inspect stored mail and reconcile your own state. Monitor delivery attempts and dead letters in the console. This combination—signed events, stable identifiers, and a read API—lets an integration recover without asking a person to forward the original email again.