Step 8: Booking amendment

Bókun supports amending confirmed (non-cancelled) bookings. Since July 2022 such amendments can be forwarded to Channel manager as well.

Current definition of amendment: booking alteration which does not change the booked rate or even product itself. Examples of amendment:

  • moving travel date to another day
  • adding or removing passengers
  • adding or removing extras
  • adding or removing pickup/dropoff

Amendments currently do not have widespread ecosystem support and in many cases Bókun’s integration adapts by issuing cancellation with new booking instead.

Booking amendment might be invoked without prior availability check. It is responsibility of the plugin to ensure that all conditions are met (sufficient availability, pickup if applicable, etc.).

Implementing amendment in Channel manager is optional. Not implementing this method results:

  • your system not receiving amendments from those sales channels which support it (e.g. Viator)
  • Bókun responding positively to such amendments from incoming sources without relaying this information further

gRPC service interface

gRPC-enabled plugins must implement the following API call:

rpc AmendBooking (AmendBookingRequest) returns (io.bokun.inventory.common.api.grpc.AmendBookingResponse) {}


REST-enabled plugins must work with the following URL:

POST /booking/amend

Request and response

Amendment request, AmendBookingRequest, has the following structure:

Plugin configuration parameters, as specified in Step 3. plugin configuration
Exactly as returned by SuccessfulBooking::bookingConfirmationCode. Mandatory if booking was successfully confirmed. In exceptional cases (e.g. booking was imported directly) this might be omitted.
Exactly as supplied with ConfirmBookingRequest::reservationData::platformId.
Reservation information; contains all the necessary data for rebooking.
Elements pertaining to confirmation (mirrors the same structure as reserve/confirm for convenience).

Plugin response must be in shape of AmendBookingResponse, and have the following structure:

see notes
Should be set if the amendment has succeeded. Similar to confirmation response, may contain ticket information (if tickets have changed), as well as SuccessfulAmendment::amendmentConfirmationCode. The latter will be used as a replacement for confirmation code.
see notes
Should be set if the amendment has failed
Did this answer your question?