Cope with ‘Postponed commit’

home > Booking phase > Cope with ‘Postponed commit’

Step 1: The MP wants to book the selected leg from the planning phase, but sends it to a TO with a 'postponed commit' scenario.

POST https://exampleTO.com/bookings/
{
  "id": "746ac-48792bb-746dac3", // provided in planning phase
}

The result must be a booking in PENDING state, unless it is rejected by the TO for some reason.

{
  "id": "746ac-48792bb-746dac3",
  "state": "PENDING", 
  ...
}

Step 2: After sending the request to all needed TO's - and they all responded positively, the MP will have to send a POST request with the operation COMMIT in it to change the booking-option into a real booking.

POST https://exampleTO.com/bookings/746ac-48792bb-746dac3/events/
{
  "operation": "COMMIT"
}

The result will be a booking object, in state CONDITIONAL_COMFIRMED. The MP has now to wait for the message from the TO that tells him it is committed or denied.

{
  "id": "746ac-48792bb-746dac3",
  "state": "CONDITIONAL_CONFIRMED",
  ...
}

Step 3: Wait for the TO to respond.
The TO will call the MPs endpoint. If the TO accepts the leg, it will send a commit:

POST https://exampleMP.com/bookings/746ac-48792bb-746dac3/events/
{
  "operation": "COMMIT"
}

But it is also possible that the TO denies the leg:

POST https://exampleMP.com/bookings/746ac-48792bb-746dac3/events/
{
  "operation": "DENY"
}

Or, there is no message before the 'expires' in the header of the result. The assumption is that it should be treated as a 'deny'.