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.

Please authenticate to join the conversation.

Upvoters
Status

New

Board

πŸ’‘ Feature requests

Date

About 2 hours ago

Subscribe to post

Get notified by email when there are changes.