Skip to main content
This guide walks you through setting up webhooks in your Quickbutik store and configuring your application to receive and process webhook events reliably.

Configuration in Quickbutik

1

Access webhook settings

Log into your Quickbutik Control Panel and navigate to Settings → Webhooks
2

Add webhook URL

Enter your webhook endpoint URL where you want to receive notifications:
Your webhook URL must be publicly accessible and respond to GET requests. Use HTTPS in production for security.
3

Select events

Choose which events should trigger webhook notifications:
  • Order events: order.new, order.done, order.cancelled
  • Product events: product.add, product.update, product.delete
4

Turn on the secret key (recommended)

Tick Use secret key? and save. Quickbutik creates a secret key for the webhook and sends it with every request as the securityhash query parameter. Open the webhook again to see the value, shown as securityhash=<your key>. See Verifying requests.
5

Test your webhook

There is no test button in the Control Panel. Trigger a real event instead, for example by saving a product when the webhook listens to product.update, and check that your endpoint receives the request. Events are sent once a minute, so allow a minute or two.

Verifying requests

Each webhook can have its own secret key. When Use secret key? is ticked on a webhook, Quickbutik adds the key, unchanged, to every request it sends to that webhook’s URLs as the securityhash query parameter:
securityhash is not calculated per request. It is not a signature or an HMAC of the request, and there is no algorithm to reproduce. It is a fixed shared secret: the same value is sent with every request to that webhook for as long as the key exists.
To verify that a request comes from your store:
  1. Open the webhook in your Quickbutik Control Panel and copy the value after securityhash=.
  2. Store it on your side as a secret, for example in an environment variable.
  3. Compare the securityhash parameter of each incoming request with the stored value. If the parameter is missing or does not match, ignore the request.
  4. Fetch the order or product through the API with the ID from the request. The request only carries the event type and an ID, so the data you act on always comes straight from Quickbutik.
Treat the key as an opaque string and compare it in constant time. Do not assume a fixed length or format.

Managing the key

  • The key stays the same when you edit the webhook.
  • Untick Use secret key? and save to remove the key. Requests to that webhook are then sent without securityhash.
  • Tick it again and save to create a new key. The old key is no longer sent, so update the stored value on your side straight away.
  • Each webhook has its own key. If several webhooks send to the same endpoint, accept the key of each one.
The key is part of the request URL, so it can end up in the access logs of your web server, load balancer or proxy. Use HTTPS, keep those logs private, and create a new key if you think it has leaked.

Development Setup

For local development, use a tool like ngrok to expose your local server:

Production Deployment

For production environments, ensure your webhook endpoint is robust and scalable:

Troubleshooting

Common Issues

Possible causes:
  • Webhook URL is not publicly accessible
  • Firewall blocking incoming requests
  • Server not running or crashed
  • Wrong endpoint path configured
  • The webhook is not active (Activate Webhook is not ticked) or does not listen to the event
Solutions:
  • Test your endpoint with curl: curl "https://your-domain.com/webhooks/quickbutik?event_type=test"
  • Check server logs for errors
  • Verify webhook URL and events in Quickbutik settings
  • Wait a minute or two, since events are sent once a minute
  • Use tools like ngrok for local testing
Quickbutik closes each request after 10 seconds and does not send it again.Possible causes:
  • Webhook handler takes too long to respond
  • Processing heavy operations synchronously
  • Database or external API calls blocking response
Solutions:
  • Always respond with 200 OK immediately
  • Process webhook data asynchronously
  • Use queue systems for heavy processing
  • Implement timeout handling
Possible causes:
  • The same endpoint URL is added to more than one webhook, or more than once in the same webhook. Each one gets its own request.
  • The same change was made more than once in the store, which creates a new event each time
Solutions:
  • Add each endpoint URL to only one webhook, and only once
  • Implement idempotent processing
  • Use the id parameter to skip an event you have already processed
  • Use database transactions for atomic operations
Quickbutik sends each event once and does not retry. A request that your endpoint did not receive, or did not answer within 10 seconds, is lost.Possible causes:
  • Endpoint was down during event
  • Endpoint did not answer within 10 seconds
  • Your own rate limiting or firewall rejected the request
  • The webhook is not active or does not listen to the event
Solutions:
  • Monitor webhook endpoint uptime
  • Respond quickly and process the event asynchronously
  • Queue received events, so a processing error on your side does not lose them
  • Regularly poll API for missed events as backup

Next Steps

Event Types

Explore all available webhook events and their data