Webhooks let you connect Quickshops to your own systems. Whenever something important happens in your store — a new order, a subscription cancellation, a failed payment — Quickshops sends an HTTP POST request to a URL you specify, so your external tools can react instantly.Documentation Index
Fetch the complete documentation index at: https://docs.quickshops.app/llms.txt
Use this file to discover all available pages before exploring further.
Events you can subscribe to
| Event | When it fires |
|---|---|
order.completed | A customer completes a one-time purchase |
subscription.created | A customer starts a new subscription |
subscription.cancelled | A subscription is cancelled |
subscription.payment_failed | A subscription renewal payment fails |
Set up a webhook endpoint
Add an endpoint
Click Add Endpoint and enter the URL of your server or service that will receive the events.
Select events
Choose which events you want this endpoint to receive. You can subscribe to one event or multiple.
Webhook payload format
Every webhook Quickshops sends is a JSON object with three top-level fields:event— the name of the event that firedtimestamp— the time the event occurred, in ISO 8601 formatdata— an object containing the details of the event
Verifying webhook signatures
Every request Quickshops sends to your endpoint includes a signature header. You should use this signature to confirm the request genuinely came from Quickshops before acting on the payload. The signature is included in theX-Quickshops-Signature header of each request. To verify it, compute an HMAC of the raw request body using your webhook’s signing secret (shown in Settings → Webhooks when you view an endpoint), and compare it to the value in the header. Only process the event if they match.
Retries and failures
If your endpoint returns a non-2xx HTTP status code or doesn’t respond within the timeout window, Quickshops will retry delivery. You can view delivery attempts and their status for each endpoint from Settings → Webhooks.Make your endpoint idempotent where possible — use the
orderId or other unique identifiers in the payload to avoid processing the same event twice if a retry occurs.