What changed
On August 27, 2026, Postmark added active webhook verification and health controls. When a webhook is created or edited, Postmark can test every enabled event type and require the endpoint to return HTTP 200 before saving. If an event type that previously worked begins failing persistently, Postmark can mark that individual event type unverified and pause its delivery while other event types on the same webhook continue. Account owners receive an alert, and the Webhooks API now includes on-demand verification plus statistics for success rate, failures and response times over the previous 24 hours.
Why it matters
Email products often discover broken webhooks only after downstream state has drifted: bounces were not processed, deliveries were not recorded or customer automations silently stopped. Postmark's new checks give builders a clearer failure boundary at configuration time and a way to distinguish one broken event path from an entirely dead webhook. Event-specific pausing can also reduce repeated failed deliveries without suppressing unrelated events. The safety boundary remains important: webhook reachability is not webhook authenticity, and Postmark's current documentation does not provide HMAC signatures for outbound webhook payloads, so endpoint authentication and payload validation still need separate controls.
Configuration can fail before a broken webhook is saved
When verification is enabled, Postmark sends representative requests for each selected event type as part of webhook creation or editing. The endpoint must return HTTP 200. The UI identifies the failing event/response, while the API can return a validation error instead of silently storing a destination that cannot accept the configured traffic. Postmark also documents an option to bypass verification when a team deliberately needs to save first and bring the endpoint online later.
Persistent failure is isolated by event type
A webhook may carry multiple event types such as delivery, bounce, open or click events. Postmark says that if one event type becomes persistently unhealthy after previously working, it can mark that event type unverified and pause delivery for that type rather than disabling the entire webhook. Other event types continue, reducing the blast radius of a broken downstream handler.
Webhook health becomes queryable
The Webhooks API includes verification actions and a statistics surface reporting recent success rate, failures and response-time information. That gives teams a way to integrate webhook health into their own monitoring instead of depending solely on application-side symptoms or manual inspection in Postmark.
Verification does not replace authentication
A server returning 200 proves that Postmark can reach a handler and that the handler accepts the test request; it does not prove that future requests cannot be forged. Postmark's current security guidance relies on controls such as HTTPS, HTTP Basic Authentication where appropriate, source-IP restrictions and application-level payload validation rather than signed HMAC webhook payloads.