Skip to main content

​
Successful delivery

A delivery is considered successful when your endpoint returns a 2xx status code within the 30-second timeout. Once a delivery succeeds, no further attempts are made for that event.

​
Retries

If a delivery fails, Zivio automatically retries it on a back-off schedule — frequent at first to catch brief outages, then spaced further apart. There are up to 10 attempts (the first attempt plus 9 retries) spread over roughly 3 days. A small random variation is added to each retry interval to avoid sudden bursts of traffic to your endpoint.

​
What counts as a failure

ResponseBehaviour
2xxSuccess — no retry.
5xx, 408, 429Temporary failure — the delivery is retried.
Other 4xxPermanent failure — the delivery is not retried.
Timeout / no responseTemporary failure — the delivery is retried.
A 3xx redirect is not followed and is treated as a delivery problem to fix on your side. Point your webhook directly at the final URL.
Returning a 2xx quickly is the best way to avoid unnecessary retries. If you cannot finish processing within 30 seconds, acknowledge the request immediately and process it asynchronously.

​
Ordering and duplicates

  • Ordering is not guaranteed. Because of retries and independent delivery, events may arrive out of order. Use the occurred_at field in the payload if order matters to you.
  • Delivery is at-least-once. An event may occasionally be delivered more than once. De-duplicate using the webhook-id header (also the id in the payload).

​
Auto-disabling

If a webhook keeps failing for a sustained period — roughly 5 days of continuous failure with no successful delivery — Zivio automatically disables it to stop sending to an endpoint that is clearly not working. When this happens, the admins who manage webhooks are notified by email. A disabled webhook stops receiving events until it is re-enabled from the Webhooks admin. Before re-enabling, make sure the underlying issue (an unreachable endpoint, an expired certificate, a changed secret, and so on) has been resolved.
A webhook is also automatically disabled if the admin account that owns it is deleted, since the webhook can no longer determine what data it is permitted to send. If you need the integration to continue, recreate the webhook under an active admin account.

​
Reviewing and replaying deliveries

The Webhooks admin records every delivery attempt. From the Deliveries view you can:
  • Filter deliveries by webhook, event type, status, event ID, and date range.
  • Open any delivery to inspect the request and response details.
  • Resend a past delivery if your endpoint missed it or you need to reprocess it.
A resent event is delivered as a new event with a new ID, so a receiver that de-duplicates by event ID will treat it as separate from the original. The delivery log keeps the original and its resends linked together so you can follow the full history.

​
Delivery history retention

Delivery records are retained for a limited window (30 days by default) and then automatically removed. Export or store anything you need to keep for longer in your own systems.