Monitor Webhook Deliveries

Inspect webhook deliveries, attempts, payloads, and responses in the SIBI Developer Portal, and re-send a delivery.

Every webhook SIBI sends to your endpoints is recorded. The SIBI Developer Portal shows those records: which events were sent, what your server returned for each attempt, and the exact payload we posted. You can also re-send any delivery from there.

Webhooks

The Webhooks page lists every webhook configured for your organization:

Selecting a row opens that webhook’s deliveries. To add, change, or remove a webhook, email us — see Receive Events.

Deliveries

A delivery is one event sent to one webhook. It holds the payload, the outcome, and every attempt SIBI made, including the attempts from a redrive.

The deliveries list shows, newest first:

A delivery that has been re-sent also carries a Re-sent badge with the time of the last redrive.

Filter and search

• Outcome narrows the list to Succeeded or Errored deliveries.
• Search payloads does a full-text search of the stored payloads, scoped to this webhook. Search for an identifier that appears in the body — a PO number, an order id, an invoice id — to find the delivery that carried it. Punctuation inside an identifier is ignored, so PO-123 and po123 match the same delivery.
• Refresh re-reads the list, and Load more pages further back in time.

Both the filters and the search only see deliveries inside the 90-day retention window.

Delivery details

Selecting a delivery opens it. The page has three sections.

Summary — the delivery id, the endpoint the payload was sent to, and, when SIBI has them, the event id and the id of the resource the event is about (for example the order id).

Attempts — one row per attempt, in order:

SIBI stores the response body only for failed attempts — for a 2xx the row reads Response body not stored for non-error response. When the request never got a response at all, the connection error is stored in its place.

Payload — the exact JSON body SIBI posted, pretty-printed, with a Copy payload button. This is the body your signature was computed over.

Redriving a delivery

Redrive re-sends a delivery’s payload to the webhook’s current URL, signed with the webhook’s current signing secret. Use it after you have fixed the endpoint that rejected the event, or after your service was down.

• The payload is unchanged — the redrive sends what was originally sent, not a fresh snapshot of the resource.
• The new attempts are appended to the same delivery, continuing its attempt numbering, and the delivery’s outcome is updated to reflect them.
• A redrive follows the same retry policy as an original send, so it can take a while to finish. The delivery shows Redrive queued until the attempt lands, then refreshes on its own.
• Redrive is unavailable while a redrive of that delivery is already running, or on a disabled webhook.
• A delivery whose payload was too large to store cannot be re-driven.

Data retention

Deliveries, their attempts, the response bodies, and the payloads are all deleted 90 days after the delivery was first sent.

• Payloads over 200 KB are not stored. The delivery still records its attempts and outcome, and the payload section reads The payload was larger than 200 KB and was not stored with this delivery. A delivery with no stored payload cannot be found by payload search and cannot be redriven. This limit only applies to what is recorded, the full payload is always sent.

• Response bodies are stored only for failed attempts, truncated at 8 KB. We log the status code for attempts that returned a 2xx, but discard the body. Connection errors are stored in place of a body, under the same 8 KB limit. A truncated body is shown with a trailing ….

Redriving a delivery does not extend its retention. The 90 days run from the original send, so a delivery near the end of its window will expire whether or not it has been re-sent.