Browse documentation

Webhooks

Webhook retries

The webhook dispatcher retries a failed delivery on your endpoint's behalf. Every attempt is logged in the developer dashboard.

Delivery budget

  • Timeout. Each attempt gives your endpoint up to 20 seconds to return a 2XX response.
  • Retries. A non-2XX, timeout, or connection error is retried with a scheduled backoff. The dispatcher makes up to 10 attempts per delivery within a window of up to 3 days.
  • Schedule. The inter-attempt delays are configured in workers/developer-platform-webhook-dispatcher/src/retry.ts. The base delays are 1 minute, 5 minutes, 30 minutes, 2 hours, 5 hours, 10 hours, 14 hours, 16 hours 40 minutes, and 16 hours 40 minutes. Carebit applies up to 10% positive or negative jitter to each delay. The cumulative retry window remains under 3 days.
  • At-least-once. Network partitions can cause the same event to be delivered twice. Dedupe on Carebit-Event-Id (equivalent to id in the JSON body).
  • Order. Events are not delivered in a strict order per endpoint. Design handlers to be commutative, or reconcile against the resource state via the public API.
  • Redirects. The dispatcher does not follow HTTP redirects. Respond 2XX from the exact URL configured on the endpoint. A 3XX response counts as a failure.
  • Auto-disable. If an endpoint fails continuously for 3 days, Carebit pauses it and emails the project's Admin and Developer StaffMembers. Re-enable it from the developer dashboard after fixing the receiver. The failure streak clears the first time any attempt succeeds.

These schedule numbers describe how Carebit dispatches. They are independent of your own retry policy against the outbound API (see Idempotency and retries).

Manual resend

Every exhausted delivery in the developer dashboard has a Resend button. Resend reuses the existing Carebit-Delivery-Id and adds exactly one attempt to that delivery. If that attempt fails, resend does not queue further retries and cannot be triggered again. Use resend to replay a specific past event after fixing the receiver, not to escalate retries.

Test events

The Send test event action in the dashboard sends a fabricated payload with livemode: false. Fixture IDs are deterministic UUIDs for Organizations that do not exist, and payloads use example.invalid addresses and clearly fake names. Test deliveries do not affect the failure streak.

Log retention

Every attempt is logged with the request headers, the raw body, the response status, the response body, and the outcome. Logs are retained for 30 days and are searchable in the developer dashboard by event type, endpoint, delivery id, and outcome.

Prefer plain text? Append ?format=md or send Accept: text/markdown to receive this page as raw Markdown.