Docs/Webhooks/Reservation

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

Verify the HMAC against the raw request body, not a re-stringified JSON object. Re-serialisation can reorder keys or change whitespace and break the signature.

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.

Tip: Acknowledge with a 2xx status within 5 seconds. Failed deliveries are retried up to 5 times with exponential backoff.Webhook reliability →

AI