Monitoring and handling failures

Webhook Monitoring Delivery log Incident response

Webhooks are quiet while they work, which makes it easy to miss when they stop. And after four failed attempts in a row a webhook switches itself off, after which events no longer arrive. This article covers what ReceiptRoller shows you about deliveries, and how to notice a stopped webhook early and recover.

What you can see

Information	Where	What it tells you
`active`	`GET /api/v1/webhooks/{id}`, and the app details page in the developer portal (Active / Inactive)	`false` means deliveries have stopped: it was paused, or it failed four times in a row and was switched off
`lastDeliveredAt`	`GET /api/v1/webhooks/{id}`, and "Last delivered" on the app details page	When a delivery last succeeded (`2xx`), in UTC. Test sends do not update it
Delivery log	`GET /api/v1/webhooks/{id}/deliveries`	The result of each of the latest 50 attempts

The delivery log is not shown in the developer portal; you get it through the API.

Reading the delivery log

curl https://receiptroller.io/api/v1/webhooks/{webhook_id}/deliveries \
  -H "Authorization: Bearer {access_token}"

[
  {
    "id": "wdl_xxxxxxxxxxxx",
    "webhookId": "wh_xxxxxxxxxxxxxxxx",
    "eventType": "receipt.created",
    "httpStatus": 503,
    "success": false,
    "attemptCount": 2,
    "errorMessage": null,
    "attemptedAt": "2026-10-26T03:16:44.0000000"
  }
]

One row per attempt, newest first, up to 50. There are no parameters to filter by period or status
attemptCount is which attempt this was for the event (1 to 4)
httpStatus is the status your server returned. 0 means the connection failed or there was no response within 10 seconds, and errorMessage says why
attemptedAt is in UTC
The event ID (X-RR-Delivery), the body and your server's response body are not recorded. To match attempts to events, log X-RR-Delivery and the time on your side
Test sends are not recorded

Noticing that deliveries stopped

ReceiptRoller does not notify you when deliveries fail or a webhook is switched off. Watch for it yourself:

Switched off: call GET /api/v1/webhooks on a schedule and alert on any webhook with active false. This is the most important check
Rising failures: look for a run of success: false rows, or rows with attemptCount of 2 or more, in the delivery log
Nothing arriving: if lastDeliveredAt has not moved for a long time during business hours, something may be wrong on your side or at the source
Your own records: keep counts of received events (per event), signature failures and dropped duplicates, plus response times, to narrow causes down quickly

Recovering

Find the cause from httpStatus and errorMessage in the delivery log, and fix your server
Confirm with a test send (POST /api/v1/webhooks/test/{id}) that you get success: true. You can test a webhook that is switched off
Switch it back on by sending { "active": true } to PATCH /api/v1/webhooks/{id}, or with the resume button in the developer portal
Events from while it was off will not arrive, so fetch that period's sales from the Transactions API to fill the gap

Common causes

Delivery log	Likely cause
`httpStatus: 0`	The URL cannot be reached (DNS, TLS certificate, firewall, server down), or it did not answer within 10 seconds
`401` / `403`	Your server rejects the signature, usually a wrong secret or not using the raw body (Signature verification and security)
`404`	The receiving path changed. A URL cannot be changed later, so register a new webhook for the new URL
`5xx`	Your processing fails. Move heavy work and calls to other services after the response (Designing resends, ordering, and idempotency)
No rows	Nothing was sent. See Webhook is not being delivered

Regular review

Delete webhooks you no longer use
Check that no webhook subscribes only to events that are not sent (receipt.updated and so on)
Check that the scheduled API fetch you reconcile webhooks against is still running

Related guides

Published: 2026-04-27 Updated: 2026-10-26