reservation.updated
Dates, guest count, status, or pricing changed on an existing reservation.
When it fires
Fires when any meaningful field on a reservation changes after creation — date shift, guest count update, status transition (e.g. confirmed → checked-in), pricing adjustment, or assigned-listing change.
Payload
Every delivery uses the same outer envelope (type, deliveryId, createdAt, data). Dedupe on deliveryId — retries reuse the same id.
{
"type": "reservation.updated",
"deliveryId": "evt_01HX5XPQ2L",
"createdAt": "2026-05-01T13:00:00.000Z",
"data": {
"id": 215906,
"confirmationCode": "HMA1234567",
"changes": {
"checkOut": { "from": "2026-06-05", "to": "2026-06-07" },
"pricing": {
"from": { "total": "1320.00" },
"to": { "total": "1640.00" }
}
},
"updatedAt": "2026-05-01T13:00:00.000Z"
}
}Verifying signatures
Every delivery includes an X-Repull-Signature header containing an HMAC-SHA256 of the raw request body computed with your subscription's signing secret. Verify it before processing — see Verify Signatures for full Node.js and Python examples.
Use the raw body
Example handler
if (type === 'reservation.updated') {
const { id, changes } = data
if (changes.checkOut) {
// Date shift — re-issue check-in instructions, re-block the calendar
console.log('Checkout moved to', changes.checkOut.to)
}
if (changes.pricing) {
// Re-charge the difference, update the owner statement
}
}Common patterns
- The changes object only contains fields that actually changed. Diff against your last-known state — do not assume any specific field will be present in every delivery.
- Fetch the full reservation after a change. The changes diff is enough to know what shifted, but downstream systems (CRM, accounting, cleaning rota) should reconcile against GET /v1/reservations/{id}.
- Best-effort ordering — a reservation.updated and a payment.completed for the same reservation may arrive out of order. Reconcile against the latest API state when ordering matters.
Related
- Full event catalog
- reservation.created
- reservation.cancelled
- Update a reservation
- Verify webhook signatures
Tip: Acknowledge with a 2xx status within 5 seconds. Failed deliveries are retried up to 5 times with exponential backoff.Webhook reliability →