Skip to main content

Expose reservation-level OTA cancellation policy in the Public API and reservation webhooks

Hello,

I would like to submit a feature request for the Hospitable Public API and reservation webhooks.

Current limitation When receiving OTA reservations (Booking.com, Airbnb, etc.), the Public API and reservation webhooks do not expose the actual cancellation policy applied to the specific reservation.

Today, we can retrieve:

  • reservation status

  • guest details

  • stay dates

  • financials

  • property-level booking policies through GET /v2/properties?include[]=bookings

However, for a specific OTA reservation, we cannot reliably determine whether the traveler booked:

  • a flexible / refundable rate or

  • a firm / non-refundable rate

Why the current property-level data is not enough bookings.booking_policies.cancellation on the property is useful, but it reflects the property configuration, not necessarily the exact cancellation terms chosen for the specific OTA reservation. For PMS integrations, channel management, accounting, support, and operational workflows, this distinction is critical at reservation level.

Requested improvement Please expose the reservation-level cancellation policy for OTA reservations in:

  • reservation webhooks:

    • reservation.created

    • reservation.changed

    • reservation.cancelled

  • reservation endpoints:

    • GET /v2/reservations

    • GET /v2/reservations/{uuid}

What would be useful A structured field, not only a free-text description.

For example, something like:

  • cancellation_policy.type

    • flexible

    • moderate

    • strict

    • non_refundable

    • unknown

  • cancellation_policy.is_refundable

    • true / false

  • cancellation_policy.free_cancellation_until

    • ISO datetime if applicable

  • cancellation_policy.penalties

    • structured rules if available

  • cancellation_policy.source

    • ota_rate_plan

    • property_default

    • manual

    • etc.

Minimum useful version If a fully structured model is not currently possible, even one reservation-level field would already help a lot, for example:

  • reservation.cancellation_policy_text or

  • reservation.is_non_refundable

Why this matters This would allow integrations like ours to:

  • distinguish refundable vs non-refundable OTA reservations

  • automate internal workflows correctly

  • improve financial and support handling

  • avoid incorrect assumptions based only on property defaults

At the moment, this information appears to be unavailable for a specific OTA reservation in the Public API, which makes robust PMS integrations harder.

Thank you.

Status: Backlog1 comment

Log in to comment and vote

Comments1

  • Andrew Schorr

    Team•

    Mar 18

    Great feedback! Thank you for highlighting this and providing such detailed information. 👏