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.createdreservation.changedreservation.cancelled
reservation endpoints:
GET /v2/reservationsGET /v2/reservations/{uuid}
What would be useful A structured field, not only a free-text description.
For example, something like:
cancellation_policy.typeflexiblemoderatestrictnon_refundableunknown
cancellation_policy.is_refundabletrue/false
cancellation_policy.free_cancellation_untilISO datetime if applicable
cancellation_policy.penaltiesstructured rules if available
cancellation_policy.sourceota_rate_planproperty_defaultmanualetc.
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_textorreservation.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.