References¶

Receiving a traveller message¶

Booking.com posts inbound traveller messages to the route you expose on your registered webhook base URL:

POST /v2/bookings/:bookingReference/chat-messages

This is the same path as the outbound send a driver message endpoint. Only the host differs. Implement the receiver as a single parameterised route, for example app.post('/v2/bookings/:bookingReference/chat-messages', handler).

Payload Fields¶

Field	Type	Description
messageId	String	A time-based UUID (v1) generated by Booking.com. Use it for deduplication. Discard duplicates silently.
content	String	The traveller's message, in the traveller's original language.
sentAt	String	The send timestamp in UTC (ISO 8601).

Sample Payload¶

{
    "messageId": "671dc1e8-a312-11f1-a9f7-567d4456d93b",
    "content": "I'm outside terminal 2, near the taxi rank.",
    "sentAt": "2026-04-28T13:17:41Z"
}

Note

Parse both timestamp formats: 2026-04-28T13:17:41Z and 2026-04-28T13:17:41.428Z.

Responses¶

HTTP 200 - OK¶

HTTP 204 - No Content¶

Return a 2xx response within 30 seconds. No response body is required.

Failure and recovery¶

Webhook delivery is best-effort and is not guaranteed. If your endpoint does not return a 2xx response within 30 seconds, Booking.com makes a limited number of redelivery attempts. After that, the message may be dropped.

Because delivery is not guaranteed, you must recover missed messages with the conversation history endpoint.

Warning

Do not rely on the webhook alone. Call the history endpoint every time a chat opens, to load the full thread, whatever the webhook status. Suppliers that do not implement the webhook can poll the history endpoint for updates.