MeSomb

Automatic webhook disabling

MeSomb automatically disables a webhook when delivery failures indicate an unavailable, misconfigured or unsafe endpoint. The rules below apply independently in live and sandbox environments.

Delivery attempts

Every HTTP 2xx response acknowledges delivery, including 200 and 204. Return success only after safely storing the event or completing its processing.

HTTP 408, HTTP 429, HTTP 5xx and temporary network failures are retried. Other HTTP 4xx responses end delivery of that event without automatic retries. Redirects are rejected: configure the final HTTPS URL directly.

Each event has at most 6 automatic delivery attempts: the initial attempt and 5 retries. Retry delays are 30, 60, 120, 240 and 480 seconds, with an additional random delay of up to 10 seconds each. These are scheduling delays, not a guaranteed delivery deadline.

Disabling rules

  • HTTP 410: the webhook is disabled immediately because the endpoint is no longer available. Reason: endpoint_gone.

  • Unsafe destination: the webhook is disabled immediately if destination security checks reject the URL, port, resolved address or a redirect. Private and internal addresses are prohibited. Reason: unsafe_destination.

  • HTTP 401 or 403: the webhook is disabled after 3 consecutive distinct events end with one of these authentication errors. Reason: authentication_failures.

  • Repeated temporary failures: the webhook is disabled when at least 5 consecutive distinct events exhaust their automatic delivery attempts and at least 30 minutes have elapsed since the first exhausted event in that sequence. Both conditions must be met when another event ends in failure. Reason: repeated_delivery_failures.

The thresholds count failed events, not individual HTTP attempts. Replaying the same failed event does not count it again. A successful delivery resets both failure counters. A terminal failure outside a category resets that category’s sequence. A success never automatically reactivates a disabled webhook.

For example, 5 events exhausting their attempts within 10 minutes do not immediately disable the webhook. The 30-minute threshold is evaluated on a subsequent terminal failure; there is no timer that disables the webhook solely because 30 minutes have passed.

What happens while disabled

Automatic disabling stops further dispatches. Events already being delivered may still finish. Pending events are retained, and new events for the automatically disabled webhook continue to be recorded for later delivery. Waiting does not consume additional attempts.

This retention of new events applies to automatic disabling. Manually disabling or deleting a webhook does not provide the same behavior.

Recovery procedure

  1. Open the Webhooks page in the MeSomb dashboard, in the affected environment, and inspect the disabling reason and delivery history.

  2. Fix the endpoint: restore availability, correct authentication or signature verification, or configure a publicly reachable HTTPS URL without redirects.

  3. Explicitly reactivate the webhook. Owners, administrators and developers with access to the application can perform this action. Changing the URL alone does not reactivate it.

  4. Reactivation clears the disabling reason and failure counters and resumes paused pending events. Events already marked FAILURE are not replayed automatically: replay them explicitly from delivery history after correcting the issue.

Manual replay and duplicate protection

Manual replay requires an active webhook and a failed event with a stored payload. Each event allows up to 3 manual replays, each with up to 6 additional attempts. Older events without a stored payload cannot be replayed.

Automatic retries use the original destination URL. Manual replay uses the current webhook URL. Both preserve the event ID and payload, while each delivery uses a fresh signature timestamp and the current signing secret.

Use X-MeSomb-Webhook-Event-Id to deduplicate deliveries; for version 2 payloads, the body id contains the same event ID. Store this ID atomically with your business processing, and acknowledge duplicates without repeating the operation.