Handling webhooks
A Webhook event is considered successfully delivered when the corresponding URL endpoint responds with a2xx HTTP status code
within 5 seconds.
If the criteria is not met, Method will reattempt 4 more times
with each new attempt being delayed according to an exponential backoff
algorithm, where the delay period between each attempt exponentially increases.
Handling duplicate deliveries
Webhook delivery is at-least-once: the same event can occasionally be delivered more than once. This happens, for example, when your endpoint processes an event but does not respond with a2xx within 5 seconds (the delivery is retried).
Every delivery includes a method-webhook-delivery-id header that uniquely identifies the
delivery. The value stays the same across retry attempts of the same event, so use it as an
idempotency key: record each processed ID and skip any delivery whose ID you have already
seen. As a general rule, we also recommend processing events idempotently: fetch the
resource referenced by the event and upsert your local state, so handling the same change
twice has no effect.
The
id field in the request body is the ID of the resource that changed, not a unique
event identifier; two different events for the same resource share it. Deduplicate using
the method-webhook-delivery-id header, not the payload.Automatic disabling
Method automatically changes a Webhook’s status when a delivery fails 5 times (the initial attempt and all retries) and more than 40% of the Webhook’s delivery attempts within the rolling 24-hour window have failed. The resulting status depends on your team’s grace period:- If the Webhook is within a grace period configured for your team (measured from the
Webhook’s creation), its
statusis set torequires_attentionand it continues to receive events. - Otherwise, its
statusis set todisabledand no further events are delivered until the Webhook is reactivated.
error is set on the Webhook object with details about the failure.
To reactivate a disabled Webhook, use the Update a Webhook
endpoint to set its status back to active. Before reactivating, ensure the underlying
issue has been resolved to prevent the Webhook from being disabled again.
Authentication
Webhook Request Validation
Webhook Request Validation
We use the
auth_token and hmac_secret you provide to enable webhook authentication.
There are 2 ways to authenticate an incoming request.2. HMAC Verification
2. HMAC Verification
If you provide an The timestamp is always included in the
hmac_secret when registering your webhook, Method will include a method-webhook-signature header in every request. This is an HMAC-SHA256 digest created using the hmac_secret as the shared secret, and computed over the string timestamp:payload, where timestamp is the value from the method-webhook-timestamp (UNIX timestamp in seconds) header (which is always included, even if no hmac_secret is provided) and payload is the raw request body.
Checking for the timestamp freshness (5 min window) is optional, but recommended.method-webhook-timestamp header, even if no hmac_secret is provided.Example: Minimal Express Server for Verifying Webhooks
Example: Minimal Express Server for Verifying Webhooks