Validate SocketLabs delivery-event webhooks
Check SocketLabs Secret Key and server scope, return the expected responses, and persist delivery feedback without treating it as incoming mail.
Reviewed
SocketLabs’ Event Webhooks report outgoing delivery, failure, complaint, and applicable engagement events. They are not its separate Inbound API for parsed customer messages.
Establish endpoint authentication and scope
- Deploy a public HTTPS receiver with a valid certificate and JSON parsing for current endpoints.
- Configure the webhook at the correct server, account, or subaccount level for your sender model.
- Validate the supplied Secret Key and expected ServerID/scope before trusting a notification. Follow the documented access scheme; it is not MailKite HMAC verification.
- Return the provider’s expected validation/success responses, and reject a mismatched secret with 401 as documented.
Do not hardcode old example IP ranges as the only source check. Provider infrastructure and account models can change; review current network requirements separately.
Store authenticated feedback
Persist notifications before returning success, tolerate additional fields, and deduplicate downstream effects. SocketLabs documents individual event POSTs rather than assuming every callback contains a batch.
Correlate failures/complaints with the outgoing application send and preserve suppression decisions against delayed events. Test endpoint validation, a bad key, duplicates, and controlled feedback.
If you need incoming replies, evaluate the separately documented Inbound API or a verified MailKite receiving address. Outbound delivery-event callbacks do not supply a mailbox automatically.