Retry failed webhooks

Failed deliveries are retried automatically on an exponential backoff — see Delivery semantics for the schedule. Manual retry exists for two situations:

• the event is exhausted (all 8 automatic attempts failed);
• you fixed your endpoint and don't want to wait for the next scheduled attempt.

Where to retry#

• Merchants → your merchant → Webhook events tab — every event for this merchant.
• Invoices → the invoice → Webhook events section — events scoped to one invoice.

What the Retry button does#

1. Resets the event and re-dispatches the stored payload verbatim — no re-serialisation, no field changes. Works for failed and exhausted events; already-delivered events are rejected to prevent double dispatch.
2. Re-signs with your current webhook secret. If you rotated the secret since the original attempt, the new signature is computed against the new secret — so your handler must already accept it.
3. Preserves the same X-Webhook-ID — your dedupe layer continues to work across retries.
4. Updates the row with the fresh status code and error.

When to retry manually#

• The event is exhausted and you've since fixed your endpoint.
• You fixed a bug and want redelivery now instead of at the next backoff slot.
• You rotated your webhook secret and want failures redelivered with the new signature.

When not to retry#

• The original 4xx was a signature mismatch you haven't fixed — you'll get the same failure.
• You already processed the event out-of-band (polling). The retry is a no-op on your business logic but still marks the event delivered.

Bulk retry#

The dashboard retries one event at a time. Most failure clusters come from a single misconfiguration — fix it once, let the automatic retries drain the backlog, and manually retry only what exhausted in the meantime.