Booking CRS API
API Methods to work with Booking CRS feature
This feature is still in Beta and you should be careful to modify OTA bookings with any changes.
API is Experimental and can be changed.
Intro
Booking CRS is an API and UI which allows the user to create, modify and cancel bookings at Channex.io.
This API is designed to cover few use cases such us:
keep information about Booking up to date if some changes is applied to Booking at PMS side
push information about Bookings created via Offline sources to be able process it over regular pipeline
By using those API you are able to:
create a new Bookings
modify existing Bookings (even if it came over OTA)
cancel existing Bookings (even if it came over OTA)
enrich existing Bookings by custom meta-information to exchange it with integrated partners such us Smart Lock service, Housekeeping Apps and etc.
Custom Information
Booking CRS API allow you to put custom information through meta
field at next objects:
booking
customer
room
You are able to put any information inside this fields in format what is suitable for your use-case.
Overrides Logic
The Booking CRS API allows you to update bookings that originate from OTAs (Online Travel Agencies). This feature helps keep bookings up to date when modifications are made on the property side. However, it's essential to understand the logic behind this functionality.
Channex operates using Booking Revisions, which act as snapshots of a booking at a given time. Each time an OTA provides an update, a new revision is created, and the existing booking is updated. These snapshots do not inherit data from previous revisions.
However, when you start using the Booking CRS API to modify OTA bookings, the system shifts to a diff-based logic for those bookings.
Each time we receive a new revision from an OTA and the affected booking has any revisions from the CRS API, we update the incoming data by calculating the difference between the previous OTA revision and the current revision.
Example
An OTA sends a booking for August 25, 2025, for a Double Room, under the name John Doe.
The PMS (Property Management System) moves the booking from a Double Room to a Single Room and updates the customer name to Hanna Doe.
The OTA later sends a modification where the customer changes their name to Alice Cooper, but the date remains August 25, 2025, and the room type remains Double Room.
How the system processes this:
When we receive the OTA modification, we compare it with the original booking and calculate the differences.
In this case, the only change from the OTA is the customer name.
As a result, we take the latest CRS revision (which has the Single Room) and apply the new customer name from the OTA update.
Final outcome: The booking will be for August 25, 2025, in a Single Room, under the name Alice Cooper.
Edge Cases
OTA Overrides Your Changes
If you change the room type from Double to Single via CRS and then receive an OTA modification that sets the room type to Triple, the final booking will reflect the Triple Room as per the OTA update.
Date Changes from OTA
If the guest modifies their booking dates via the OTA (e.g., changes the arrival date or extends their stay), the system will reset the selected room type to the original room type from the latest OTA revision.
FAQ
What happens after you make any edits to a booking?
We will create a modification and the booking will be sent to the PMS as usual
What happens if the OTA will send a modification after you have modified it?
We will check the last OTA booking vs the new version and only save the changes, it will not revert your changes that you made. More details below
Why use this feature?
If you would like Channex to have the same booking data as your PMS, it will be possible to connect applications in the future that need to read and edit bookings. Example: check-in apps. door locks, Revenue Management, Upselling etc.
API Methods
Create Booking
POST /api/v1/bookings
Payload:
Operation to create Booking and save it inside database is asynchronous, as result, if you trigger request immediately after receiving response you can get 404 Error.
Create Booking operation working based at regular logic and will trigger all associated web-hooks and availability changes (depending to Property settings).
Update Booking
Property should have Booking CRS App installed to have access for Booking CRS API.
PUT /api/v1/bookings/:booking_id
Payload:
Operation to create Booking and save it inside database is asynchronous, as result, if you trigger request immediately after receiving response you can get 404 Error.
Update Booking operation working based at regular logic and will trigger all associated web-hooks and availability changes (depending to Property settings).
Last updated
Was this helpful?