reservation.cancelled

A reservation was cancelled by the guest, host, or platform.

When it fires

Fires once when a reservation transitions to a cancelled status. The reservation row remains queryable through the API afterwards — it simply has status: "cancelled".

Payload

Every delivery uses the same outer envelope (type, deliveryId, createdAt, data). Dedupe on deliveryId — retries reuse the same id.

{
  "type": "reservation.cancelled",
  "deliveryId": "evt_01HX5XPQ2M",
  "createdAt": "2026-05-01T14:00:00.000Z",
  "data": {
    "id": 215906,
    "confirmationCode": "HMA1234567",
    "cancelledAt": "2026-05-01T14:00:00.000Z",
    "cancelledBy": "guest",
    "reason": "guest_requested",
    "refund": {
      "amount": "1320.00",
      "currency": "USD"
    }
  }
}

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.

Example handler

if (type === 'reservation.cancelled') {
  const { id, refund, cancelledBy } = data
  // Free the calendar, notify the cleaner, push the refund through accounting
  unblockCalendarFor(id)
  if (refund && refund.amount) recordRefund(id, refund)
}

Common patterns

• Always look up the full reservation via GET /v1/reservations/{id} before issuing refunds. The webhook tells you the reservation was cancelled and the platform-side refund amount, but your books may have additional fees, deposits, or upsells that need separate handling.
• Distinguish by cancelledBy. guest, host, and platform cancellations often have different refund policies and downstream actions (re-list the dates, trigger insurance claim, comp the cleaner).
• Idempotent on deliveryId. A retried delivery should not double-refund — guard with a unique constraint on deliveryId.

Related

• Full event catalog
• reservation.created
• reservation.updated
• Cancel a reservation
• Verify webhook signatures