{
"id": "evt_9pQ2vX7mKdR4tYb1nZ3sLwCe",
"created_at": "2026-07-28T18:41:03Z",
"type": "delivery.courier_location",
"data": {
"delivery_id": "<string>",
"external_id": "<string>",
"location": {
"lat": 123,
"lng": 123
},
"updated_at": "2023-11-07T05:31:56Z"
},
"test": true
}The courier moved
The courier position ping, roughly every twenty seconds while a trip is
in motion. Consume it if you render your own map; the branded
tracking_url on the delivery is the alternative that needs no
integration at all.
data is DELIBERATELY NOT the full delivery object: one of these lands
every few seconds for the whole trip, and re-sending the customer’s
name, address and phone in each would move a lot of personal data to say
the courier drove a block.
This is the ONE event that is never retried. A failed ping is superseded by the next one, so redelivering it minutes later would put a stale position on top of the fresher one you already have.
{
"id": "evt_9pQ2vX7mKdR4tYb1nZ3sLwCe",
"created_at": "2026-07-28T18:41:03Z",
"type": "delivery.courier_location",
"data": {
"delivery_id": "<string>",
"external_id": "<string>",
"location": {
"lat": 123,
"lng": 123
},
"updated_at": "2023-11-07T05:31:56Z"
},
"test": true
}Headers
Proves the event came from us. The value is t=<unix seconds>,v1=<hex>,
where the hex is an HMAC-SHA256, keyed on your signing secret, over the
string "<t>.<raw request body>".
To verify: split the header on the comma, rebuild "<t>.<body>" from
the RAW bytes you received (never a parsed and re-serialized object, or
whitespace and escape sequences will change the digest), compute the
HMAC, and compare it to v1 in constant time. Reject anything that does
not match.
Then check the clock. Reject an event whose t is more than 5 minutes
away from now in EITHER direction: a t far in the past is the replay
this scheme exists to stop, and one far in the future is the same attack
with a clock nobody checked.
Two secrets can be active at once so you can rotate without downtime: add the new one, accept either, promote it, then drop the old one. We always sign with the primary.
"t=1753728063,v1=8d2f4a1b6c7e9f0a1b2c3d4e5f60718293a4b5c6d7e8f90a1b2c3d4e5f607182"
Body
The fields every event shares. Delivery is at-least-once and unordered
by design: dedupe on id, and order by created_at or by the object's
own timestamps rather than by arrival. type and data are added by
each event, because their values depend on which event it is.
The event id, evt_ prefixed. Dedupe on this.
"evt_9pQ2vX7mKdR4tYb1nZ3sLwCe"
When the event was recorded, ISO-8601 in UTC.
"2026-07-28T18:41:03Z"
Which event this is.
delivery.courier_location The reduced body of a delivery.courier_location event. Correlate it
with a delivery you already hold; it is not the delivery object.
Show child attributes
Show child attributes
Present, and true, only on a test event you asked for with
POST /v1/test_webhooks. A real event does not carry the field at
all. A test event's data is a sample whose ids resolve to nothing.
true
Response
Return any 2xx to acknowledge the event. This one is never retried.