Webhooks allow you to receive status updates on orders you have submitted as they move through the order lifecycle.
Processing webhooks is very important, as otherwise you will not be notified of any issues that may prevent your orders from being processed.
If you have an Editor API integration, please follow the documentation here instead.
WHCC may send the same webhook notification more than once for the same order. This is normal, not a bug. Key on (ConfirmationId, SequenceNumber, event type) before acting on a notification, and treat a repeat as a reconcile rather than a discard — a later delivery can carry more data than the earlier one. See Delivery, Retries & Idempotency for the full explanation, the retry schedule, and the response timeout.
WHCC sends webhooks in one of two formats, depending on when your integration was set up:
V2 — JSON request bodies. Documented in Webhook Types.
V1 — legacy, form-encoded (application/x-www-form-urlencoded) request bodies. Documented separately in V1 Webhook Format.
Check the Content-Type header on an incoming webhook request if you're not sure which one you're receiving.
Register a URI for WHCC to post webhook requests to.
Verify the webhook URI belongs to you by returning a verification code WHCC sends to it immediately after registration.
Once your callback URI is registered and verified, the Webhook Sandbox lets you trigger a Shipped, Processed or Order Cancelled webhook on demand, without placing an order and waiting for it to ship. It is available on the sandbox environment only.
Additionally, WHCC signs all webhook requests with an HMAC signature in order to verify it's from WHCC and intended for your consumption.
Register and verify a webhook callback URI
Delivery, Retries & Idempotency — read this before you build your handler