From integration to first booking
The eight calls between an empty project and a confirmed reservation.
By Ipponsoft
Most API integrations fail in the middle: the first call works, the happy path works, and then the transactional edge cases arrive and the design has to change.
The ApiXV flow is deliberately short and explicitly split between reads and writes, so the shape of your integration is settled before you write the booking code.
Read first
1. Datasets. Pull board codes, amenities and reference data once and cache it. This is the point of truth — do not hardcode a board code list from documentation, including ours.
2. Select hotels. Resolve the properties you care about, by ApiXV UID or by a GIATA or Bedbank code you already hold.
3. Availability options. Ask for live options across your selected hotels for a date
range and occupancy. Every option comes back with an option_uid.
Then write
4. Confirmation. Confirm a specific option. This is where price movement surfaces, and
where deltaprice — the variation you are willing to accept between quote and book — does
its work. You receive a quote_uid.
5. Booking. Book the confirmed option and attach a client_reference so the booking is
findable in your own systems. You receive a booking_uid.
Then live with it
6. List bookings. Current and historic reservations.
7. Amendment. Change an existing booking.
8. Cancellation. Cancel one, receiving a cancellation_uid.
The part worth planning for
Steps 4 and 5 are where integrations get rebuilt. Availability is a snapshot; between seeing an option and committing to it, a price can move or the allocation can disappear.
Decide early what your system does when a confirmation comes back at a different price than
the search showed. Setting a deltaprice tolerance and handling the rejection path is
twenty minutes of work at the start, and a rewrite six months in.
Sandbox mirrors production behaviour with booking disabled, so steps 1 through 4 can be built and tested in full before you have production credentials.