Skip to main content
Wasl uses webhooks to push event-driven notifications directly to your server so that your Wasl can react to order and delivery changes without polling. Whenever a key event occurs — such as a driver picking up an order, busy mode being activated, or a delivery being completed — Wasl sendsWasl an HTTP POST request containing a JSON payload to the webhook URL you have registered in your account settings. You do not call webhook endpoints yourself. Instead, you expose a URL on your own infrastructure, register it with Wasl, and Wasl calls it on your behalf as events occur.

Security Verification

Every webhook payload includes a webhook_token field. When you receive a webhook, you should compare this token against the secret value you configured in your Wasl account. Reject any request where the token does not match — this protects you against spoofed or replayed webhook calls from third parties.
Never process a webhook payload without first validating that the webhook_token matches your configured secret. Skipping this check could allow malicious actors to inject fake events into your system.

Responding to Webhooks

Your webhook endpoint must respond with an HTTP 200 status code to acknowledge successful receipt. Wasl interprets any non-200 response — or a connection timeout — as a delivery failure and may retry the request.
All webhooks are delivered as:
Keep your handler lightweight. Acknowledge the webhook immediately with a 200 response, then process the payload asynchronously if heavier work is needed.

Webhook Event Types

Wasl sends four categories of webhook events to your registered endpoint:

Status Update

Order delivery status changes, driver location, and tracking links.

Busy Mode

Activation and revocation of busy mode — pause order submissions while active.

Post-Order Creation

Delivery info and estimated times sent immediately after order creation.

Order Update

Final delivery fee and distance sent after order completion.