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.
Please authenticate to join the conversation.
New
π‘ Feature requests
About 2 hours ago
Get notified by email when there are changes.
New
π‘ Feature requests
About 2 hours ago
Get notified by email when there are changes.