Skip to main content
Webhooks allow the Method API to notify your application when certain events occur. To receive Webhook notifications, create a Webhook by registering a URL pointing to your application where triggered events should be sent to. This URL is where Method will send event information in an HTTPS POST request.

Handling webhooks

A Webhook event is considered successfully delivered when the corresponding URL endpoint responds with a 2xx 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 a 2xx 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 status is set to requires_attention and it continues to receive events.
  • Otherwise, its status is set to disabled and no further events are delivered until the Webhook is reactivated.
In both cases an error is set on the Webhook object with details about the failure.
Monitor your Webhook endpoint’s health to avoid exceeding the 40% failure threshold. Even intermittent failures can accumulate over a 24-hour window and trigger automatic disabling. We recommend responding with a 2xx status code immediately and processing webhook data asynchronously.
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

We use the auth_token and hmac_secret you provide to enable webhook authentication. There are 2 ways to authenticate an incoming request.
The token for request validation will be sent as a base64-encoded string in the Authorization header of the webhook. You can verify the request originated from Method by base64-encoding your auth_token and comparing it to the incoming header value to ensure the integrity of the event.
If you provide an 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.
The timestamp is always included in the method-webhook-timestamp header, even if no hmac_secret is provided.

Webhook Objects

Webhook event object

Webhook Event Types