# Postmark webhooks can now verify themselves and pause only the failing event type Postmark now actively verifies webhook endpoints when they are configured, exposes 24-hour health statistics, and can pause delivery for a persistently failing event type without disabling the rest of the webhook. The change turns webhook reliability from a mostly passive retry problem into an inspectable operational surface: configuration tests, event-specific failure state, owner alerts and health endpoints give email systems earlier warning when downstream integrations are broken. - Status: Active - Published: 2026-08-28T11:06:33+12:00 - Updated: 2026-08-28T11:06:33+12:00 - Categories: Web Development, Marketing & Distribution, Email & Lifecycle, Developer Tools - Tags: API reliability, email delivery, Postmark, webhooks - Canonical HTML: https://beyondthe.news/dossiers/postmark-webhook-verification-health-event-pause ## 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. ## Key details - Postmark announced active webhook verification on August 27, 2026. - Webhook creation/editing can test each enabled event type and require an HTTP 200 response. - API callers can bypass the initial check with the documented verification option when needed. - A persistently failing event type can be marked unverified and paused without stopping other event types on the same webhook. - Postmark notifies the account owner when a webhook needs attention. - The Webhooks API exposes on-demand verification and recent webhook health statistics including failures, success and response-time information. - The change applies to outbound Postmark webhooks; it is separate from inbound email processing. - Postmark's current outbound-webhook guidance does not provide HMAC signature verification, so reachability/health and request authentication remain separate concerns. ## Builder takeaways - Treat webhook verification failure as a deployment signal: do not promote a new handler until every event type your application depends on passes a real Postmark test. - Monitor Postmark webhook statistics alongside your own queue/consumer metrics so you can distinguish provider delivery failure from application processing failure. - Build handlers so one event type cannot take down unrelated flows; Postmark's event-specific pause behavior makes that separation operationally useful. - Alert on paused/unverified events quickly because suppressed bounce or delivery updates can cause customer state and suppression logic to drift. - Keep webhook authentication independent from health checks. Use HTTPS, narrow credentials/IP controls where practical and validate event structure and expected server/account identifiers. ## What to watch - Whether Postmark adds signed webhook payloads or another first-class cryptographic authenticity mechanism. - Exact thresholds and retry behavior that cause an event type to become unverified/paused. - Whether health/statistics data gains longer retention or push-based alert integrations. - How event-specific pausing interacts with replay/recovery after an endpoint is verified again. ## Uncertainties - Postmark's public documentation does not expose every internal threshold used to classify persistent failure. - Webhook statistics cover a recent operational window rather than a complete audit history. - Successful verification establishes endpoint reachability and response behavior, not the correctness of downstream business logic. - Authentication requirements vary by deployment and remain the integrator's responsibility. ## Sources - [Postmark product updates](https://postmarkapp.com/updates/) — Postmark · primary_changelog · 2026-08-27T00:00:00+12:00. Primary announcement for self-verifying webhooks, event-specific health behavior and operational visibility. - [Webhooks overview](https://postmarkapp.com/developer/webhooks/webhooks-overview) — Postmark · primary_documentation. Current behavior and implementation guidance for Postmark outbound webhooks. - [Webhooks API](https://postmarkapp.com/developer/api/webhooks-api) — Postmark · primary_api_documentation. Current verification, webhook management and statistics API surfaces. - [Postmark Manual](https://postmarkapp.com/manual) — Postmark · primary_documentation. Current webhook security and operational guidance.