Public Webhooks: push order, shipment, and invoice events to your own system

Subscribe to Docklify events — order created, order fulfilled, shipment shipped, invoice issued, delivery completed — and receive them as signed HTTPS posts on your own endpoint, with test pings, automatic retries, and a delivery log.

Public Webhooks turn things that happen in Docklify into messages to your own system. The moment an order is created, a shipment is handed to the carrier, or an invoice is issued, Docklify sends an HTTPS post to an address you control. Typical uses: sync orders into your ERP or accounting software, notify your own customers in your own words, feed your dashboards, or kick off a downstream process without polling an API.

Events you can subscribe to#

• order.created — a sales order is created (manual entry, client portal, or CRM conversion).
• order.allocated — a sales order is allocated and inventory is reserved for it.
• order.fulfilled — a sales order is fully fulfilled; includes the tracking number and carrier.
• order.cancelled — a sales order is cancelled; includes the cancel reason code.
• order.delivered — a sales order is marked delivered.
• shipment.fulfilled — a WMS shipment is handed over to the carrier; includes the tracking number.
• receipt.completed — an inbound receipt is fully received, all lines in.
• inventory.adjusted — inventory is adjusted directly on a location.
• invoice.issued — an accounts-receivable invoice is generated. New invoices start as drafts; the status field shows the current status.
• delivery.completed — a last-mile delivery is signed for and completed, with proof of delivery captured.
• test.ping — the test event. Send it any time to check that your endpoint is reachable and your signature check works.

Create a subscription#

1. Open Integration → Webhooks and click New subscription.
2. Name: give it a name your team will recognize, for example “ERP sync”.
3. URL: the https address on your server that will receive the events. It must use https and resolve to a public address — private, LAN, or loopback addresses are rejected.
4. Events: tick the events you want. You can change the selection later at any time.
5. Save, then copy the signing secret — it starts with whsec_. Store it in your server configuration; you need it to verify that deliveries really come from Docklify. You can view it again, or rotate it, on the Webhooks page at any time.

What your receiver must do#

Every delivery is an HTTPS post with a JSON body — the envelope. The envelope says what happened (type), when (created_at), and carries the details in data:

{
  "id": "<event id>",
  "type": "order.fulfilled",
  "created_at": "2026-10-20T12:00:00.000Z",
  "organization_id": "<your organization id>",
  "data": {
    "order_id": "<order id>",
    "order_no": "SO-1001",
    "status": "fulfilled",
    "tracking_number": "<tracking number>",
    "carrier_code": "ups"
  }
}

• Dedupe by id: delivery is at-least-once. Retries and manual redeliveries reuse the same event id, so keep the ids you have processed and skip repeats.
• Answer 2xx, and answer fast: any 2xx status means success. Deliveries time out after 10 seconds, so if your processing is slow, store the event first, answer 200, then process it.
• Anything else counts as a failure: a non-2xx status, a redirect (3xx is not followed), a timeout, or an unreachable address — all of them trigger the automatic retries described below.

Verify the signature#

Anyone who knows your URL could post fake events to it, so every delivery is signed — check the signature before you trust the data. The full specification (header names, the exact algorithm, and one-line Node and Python examples) lives in the API documentation, in the Webhooks section. The points that matter most:

• Every delivery carries the header X-Docklify-Signature, shaped like t=<unix seconds>,v1=<hex>. The same delivery also carries X-Docklify-Event (the event type) and X-Docklify-Delivery (the delivery id).
• v1 is the hex HMAC-SHA256 of the string “<t>.<raw body>”, keyed with your subscription signing secret.
• Always compute over the raw request body, exactly as received. Never parse the JSON and re-serialize it first — spacing and key order change, and the signature will not match.
• If the signature does not match, do not process the event.

Send a test event#

1. On Integration → Webhooks, open your subscription and choose Send test event.
2. Docklify immediately delivers a test.ping to your URL. Test events can be sent to any subscription, even though test.ping is never in its event list.
3. Check the delivery log: a delivered row there, plus a verified signature on your server, means you are ready for real events.

Delivery log and troubleshooting#

Every delivery is recorded in the delivery log (Integration → Webhooks → Deliveries): the event type, the status (pending, delivered, or failed), how many attempts were made, the last HTTP status code and error, and the next retry time. A failed delivery retries automatically after 1 minute, 5 minutes, 30 minutes, 2 hours, and 6 hours — six attempts in total. After the last attempt it stays failed until you redeliver it manually from the log; redelivery reuses the same event id, so your dedupe keeps it safe.

• Address unreachable: your server is down, the URL is wrong, or the name does not resolve to a public address. Fix the endpoint, then redeliver from the log.
• Certificate problems: an expired or self-signed TLS certificate fails the delivery. Use a valid certificate from a public certificate authority.
• Non-2xx response: your receiver crashed or rejected the event. Read the status code and error in the log, fix the cause, then redeliver.
• Timeout: your receiver took longer than 10 seconds. Answer 2xx first and do the heavy work in the background.
• Signature mismatch on your side: usually a re-serialized body, or an old secret still in use after a rotation — see Verify the signature above.

Pause a subscription and rotate the secret#

• Pause: set the subscription to Paused on the Webhooks page. While it is paused, Docklify does not deliver new events to it. Resume it at any time — pausing is the safe way to take an endpoint offline for maintenance.
• Rotate the secret: if a secret may have leaked, or a teammate who knew it has left, rotate it on the subscription page. After rotation, deliveries are signed with the new secret only, so update your server at the same moment — a receiver still using the old secret will reject new deliveries.