Status webhooks

Once a booking exists, you don't poll for its progress — Addison Lee pushes status updates to an HTTP endpoint you host. As a booking moves through its lifecycle, the Quickbook platform reads each event from a queue and forwards it to you as an HTTP POST request.

This is the inverse direction of the order API: here Addison Lee is the client and your service is the server. The full message catalogue is in the Webhooks reference.

The endpoint you provide

You expose a single HTTPS endpoint that accepts POST requests with a JSON body. Every message shares a common envelope and is distinguished by its status field:

{
  "status": "ALLOCATED",
  "job": {
    "number": 660531,
    "uuid": "d65bc9a2-9e01-451c-a483-12b208127fe7"
  },
  "account": {
    "number": 100000
  },
  "dates": {
    "event": "2026-07-09T01:00:00.000+01:00",
    "sent": "2026-07-09T01:00:00.100+01:00"
  },
  "partner_reference": {
    "booking": {
      "id": "7d037cec-7d65-4ea9-8105-1247ee5f0a60"
    }
  },
  "allocation": {
    "type": "DRIVER",
    "driver": {
      "name": "SMITH, JOHN",
      "callsign": "D56",
      "contact": "07000000000"
    },
    "vehicle": {
      "class": "F",
      "reg": "AA00AAA",
      "model": "MULTIVAN LIFE PHEV S-A"
    }
  }
}

The status field is a discriminator: each value maps to a distinct payload with its own additional fields. See Status types for what each one carries.

Acknowledging a message

Respond with 200 OK and a small JSON acknowledgement once you've accepted the message:

{
  "success": true,
  "message": "accepted"
}

• Return 200 only after you've durably stored (or safely enqueued) the update.
• Return a non-2xx status if you couldn't process it, so it can be retried.
• Process quickly and do heavy work asynchronously — acknowledge first, then handle.

Authentication

Webhooks are authenticated with HTTP Basic Auth. Each request carries an Authorization: Basic <base64(user:password)> header using credentials agreed during onboarding. Reject any request whose credentials don't match.

This is different from the order API, which uses an AL client_id:client_secret token — see Authentication.

Delivery, ordering, and idempotency

• Correlate by job.uuid (and partner_reference.booking.id) to attach an update to the right booking on your side.
• Expect retries. A message may be delivered more than once if you're slow to acknowledge or briefly unavailable — make your handler idempotent.
• Don't assume strict ordering. Use the dates.event timestamp to order updates and ignore any that are older than the state you've already recorded.
• TRACKING messages arrive frequently and independently of the booking flow; treat them as live-position pings rather than lifecycle transitions.
• Allowlist the source IPs. Requests always come from a fixed set of Addison Lee addresses — see Source IP addresses.

In the reference

Open the Webhooks reference to see the exact schema and a worked example for every status message your endpoint can receive.