Supported platforms

BigCommerce

First-class support: register webhooks from the dashboard (or with a generated command), events labelled with their scope, deep links back to the order or product in your control panel, and replay. The docs and examples are written BigCommerce-first.

WooCommerce

First-class support: register webhooks from the dashboard against any WordPress install (subdirectories included), the twelve core topics plus custom action.* hooks, saved store key pairs encrypted at rest, and events labelled from the x-wc-webhook-topic header. Set a webhook secret at registration and your real handler can verify the X-WC-Webhook-Signature on every delivery we forward or replay to it.

One WooCommerce behaviour worth knowing: a webhook is disabled by the store after five consecutive failed deliveries. A CommerceHook endpoint always answers 2xx, so webhooks pointed at us stay alive while the handler behind them is being fixed.

Square

First-class support: register a subscription from the dashboard (sandbox or production) against the event catalogue (orders, payments, refunds, inventory, customers, invoices and more), tokens encrypted at rest, and events labelled from the delivery’s own headers. Square returns the signing key when the subscription is created, so signature verification is automatic on every delivery you register through us, with no secret to paste. The inspector reads the resource type and id from each event and offers the exact API call to fetch it, plus a link into the Square Dashboard for the resources Square exposes a page for.

Shopify

First-class support: register topics from the dashboard over the GraphQL Admin API using a custom app’s token, one subscription per topic, tokens encrypted at rest. Save the app’s API secret key with the store and every delivery is signature-checked against it. The inspector links each event straight to the exact record in your Shopify admin (orders, draft orders, products, customers) and offers the GraphQL call that fetches it.

The custom app is where the three values come from: the myshopify domain, the Admin API access token and the API secret key. On stores that already have one under Settings, then Apps and sales channels, then Develop apps, use it. Shopify closed that creation path to new merchant stores in January 2026, so on a newer store you create the app in the Dev Dashboard instead; the three values are the same ones.

Two Shopify behaviours worth knowing. Shopify retries a failed delivery eight times over four hours, then silently removes the subscription; an endpoint that always answers 2xx never triggers that. And webhooks created by hand under Settings, then Notifications are signed with a different, store-level secret. If you saved your app secret with the store, those deliveries show a signature mismatch, which is the inspector being honest: the body does not match the key it holds. Register through the dashboard or the API for the tick.

Stripe

Save a Stripe API key and register events across payments, checkout, customers, subscriptions, invoices, refunds and disputes. One Stripe webhook endpoint carries every event you tick, and Stripe returns its signing secret at creation, so deliveries verify from the first one.

Stripe is the one platform here where a key can be cut down to exactly this job: a restricted key with write access to Webhook Endpoints and read access to Connect Accounts is enough, and the register panel says so.

Each delivery announces whether it is test or live money, so deep links land in the matching Dashboard, and a payload’s cross-references (an invoice’s customer and subscription) become links of their own. There is more detail than fits here in the Stripe guide, including the manual signing-secret fallback and the v2 event destinations posture.

Anything else that speaks HTTP

An endpoint accepts any request, so any platform or service that can call a URL works today. That means any method, not only POST: senders use PUT and DELETE for CRUD-style deliveries and those are captured like any other. It means any body, not only JSON: a form-encoded or plain-text body is stored exactly as sent rather than rejected for failing to parse.

Four things are kept for every delivery: the payload, the headers, the method, and the query string. The last one matters more than it sounds, because plenty of senders put meaning in the URL rather than the body, a shop domain or a topic or a signature. It is stored raw, so a repeated key survives instead of half of it disappearing into an object.

Two exceptions on the headers, both for safety rather than space. A header that carries a credential (Authorization, Cookie, Proxy-Authorization) is stored with its value replaced by [redacted], so you can see the sender attached one without us holding it. And the headers Cloudflare adds on the way in (cf-*, x-forwarded-*, x-real-ip, true-client-ip) are not stored at all; that set includes the sender’s IP address, which the inspector never needed. Signature headers are neither: they are kept exactly as sent, because verifying them is the point.

GitHub deliveries are recognised and badged by their headers. Events with no recognised platform simply show without a badge.