An update has been deployed to resolve an issue where some requests to the /reservations endpoint were returning a 500 Internal Server Error.
The behavior was limited to the API response only — reservations were still being created successfully — but the response payload was failing due to data becoming corrupted under certain conditions.
The update ensures the request is now handled and parsed reliably, and the endpoint returns the appropriate success response as expected.
An update has been deployed to resolve an issue where the "down_payment_amount" returned from POST/unit_quotes, POST/reservations, and the system-side reservation record could become inconsistent under certain conditions. The "down_payment_amount" calculation and persistence flow now align across all endpoints.
The Booking Handler via POST/reservations has been updated to block reservation requests for supplier accounts that are not active.
Reservations will now be rejected when:
The supplier is no longer signed up, or
The supplier’s account has reached its expiration date.
The API now returns an appropriate error response when booking attempts are made into inactive or expired accounts.
A deployment has been released to re-implement support for the Channel Host Fee (CHFSYSTEM) . Partners can now include the Channel Host Fee as a discount line item within the "financials" object when creating reservations through the /reservations endpoint. This ensures accurate calculation for connected channels.
Example usage:
An update was deployed to resolve an issue with the /unit_quotes endpoint where the "item": "Booking Fee" was not being included in the response when configured as a Flat Fee. The "item": "Booking Fee" now returns and calculates correctly for all fee types.
An update has been made to resolve an issue where "extras" configured as "mandatory: true" were not being included in the "financials" object of the /unit_quotes endpoint. These "extras" now return correctly and align with system configurations.
An update has been deployed to fix an issue where the "booking_fee" was being incorrectly added to the "cleaning_fee" total post-reservation creation. The "booking_fee" now applies correctly to its configured fee "type".
Addressed a problem where "extras" configured as "mandatory": true were being included in /unit_quotes and /reservations endpoints even when “Include Mandatory Extras” was disabled. The API now aligns with system-side configurations.
Resolved an issue with the /unit_taxes endpoint where requests containing multiple management_company_user_ids could return a 404 Not Found response. The endpoint now returns results as expected.
Corrected quoting behavior in the /unit_quotes endpoint where supplier rate multipliers could be applied multiple times. The API now mirrors system-side rate calculations for consistent results.
An update has been deployed to persist fallback rate logic across the quoting engine when requested, ensuring consistent behavior when "fallback_rates" are applied.
An update has been deployed to correct an issue with "payment_schedule" not accurately reflecting the "paymnent_status" across the /reservations endpoints.
Additional fields within the financials.payments object for both the **POST** and **PUT** /reservations endpoints have been added to the API documentation for consistency with the live API model.
Update to the /unit_calendars endpoint to resolve an issue where calendars were being returned incorrectly when a rate set was not configured, or when the endpoint attempted to apply fallback automatically.
The calendar response now reflects the actual end of the configured rate set:
If there is a break in the rate set within the requested time span, the calendar will end at the break.
If the rate set is continuous but ends before the requested end date, the calendar will return only up to the last configured date in the rate set.
Update to the /unit_calendars endpoint to support the fallback_rates parameter. When enabled, this parameter creates a fallback rate set that extends the calendar view beyond explicitly configured rates.
Note: The calendar is designed to show absolute availability. To distinguish between standard configured rates and fallback coverage, compare responses with and without the fallback_rates parameter enabled to identify which dates are being filled by fallback.
