--- search: tags: - Webhooks - GET seo: description: >- Returns webhooks across the account. Optionally filter by shopid or sellerid query parameter. Reference for the GET /webhooks endpoint in the Bolder API v2 API. sidebar: badge: GET label: List webhooks title: List webhooks type: openapi-operation --- Returns webhooks across the account. Optionally filter by `shop_id` or `seller_id` query parameter. ## Delivery payload guarantees Every order-related event payload (`orders.created`, `orders.updated`, `orders.updated.*`) is built from the same serializer and always includes both `id` (numeric order id) and `code` (the order's public-facing reference/permalink) — neither is ever omitted. ## Retries and automatic disabling Two independent counters are involved — don't confuse them: - **Per-event retries (up to 10, over ~24h)**: each individual event delivery (e.g. one order's `orders.updated`) is retried by the delivery worker up to 10 times with growing backoff, spread across roughly a day (a few minutes after the 1st failure, up to ~24h after it by the 10th and final attempt) — this gives a temporarily-down endpoint a full day to recover before this specific event delivery is given up on. - **Subscription-wide `error_count` (disables at 100)**: every failed attempt across *all* events (including each of the 10 per-event retries above) increments `error_count` on the subscription. Reaching 100 sets `status` to `failed` and stops all further delivery — in practice that means roughly 10 different order events each exhausting their full retry chain with no successful delivery in between, since **any single successful delivery resets `error_count` to 0**. There's no fixed time bound on this: it depends on how many order events fire while your endpoint is down. Delivery outcomes are tracked on the subscription independent of the worker retries: - A `410 Gone` response from your endpoint immediately sets the subscription's `status` to `disabled` — no further attempts are made, regardless of `error_count`. - Any other non-2xx response (or timeout) increments `error_count`. Timeouts and a handful of transient upstream errors (502/512/523) don't count toward the disable threshold; other non-2xx responses do. - A `failed` (or `disabled`) subscription can be re-enabled at any time via `PUT /webhooks/{id}/reactivate`, which resets the error count.