Ducroire: finalize a booking with payment

  • Booking
  • Booking
  • 2 routes
How do I create a booking and validate it with one or more payments?

This scenario documents a short flow used to turn a ready proposal into a confirmed booking. It starts by creating the booking and then validates it by registering one or more payments on the created file.

It is useful when an integration needs to secure the transition from proposal to booking while keeping track of the returned booking_id and option durability.

Overview

This scenario documents the Ducroire flow as a short booking finalization journey. POST/v3/bookings creates the booking from a ready proposal and returns the booking_id together with option durability information. PATCH/v2/bookings/{booking_id} is then used to validate the booking by making one or more payments.

Prerequisites

  • Have a valid x-api-key.
  • Send an accept-language consistent with the proposal creation context.
  • Prepare a proposal that already contains attendee information.
  • Reuse the booking_id returned by the creation step.
  • When your integration context requires it, send a valid bearer token.
  • The exact request body schema is not visible in the available sources for either route and must therefore be verified separately before implementation.

Expected result

At the end of the flow, the integration has created a booking and attempted its payment validation on the same file.

Process workflow

Legend:
Mandatory
Optional
1

Create the booking from a proposal

Optional

Use this route to create a booking from a ready proposal before validating it with payment.

Prerequisites

  • Send accept-language consistent with the proposal creation context.
  • Send x-api-key, and authorization when required by the integration context.
  • Prepare a booking payload based on a proposal that already contains attendee information.

Calling CURL

curl -X 'POST' \
  'https://api.clubmed.com/v3/bookings' \
  -H 'accept: application/json' \
  -H 'accept-language: en-US' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  --data-raw @booking-from-proposal.json

Example answer

{
  "booking_id": "654321",
  "households": [
    {
      "attendees": [
        {
          "customer_id": 987654,
          "type": "MAIN"
        }
      ]
    }
  ],
  "option_durability": {
    "is_reliable": true,
    "expiration_date_time": "20160415T10:23:00.234Z"
  }
}

info: Keep the same accept-language as the proposal creation step to avoid inconsistencies between proposal and booking contexts.

Response codes

  • OK Response (200): returns the new booking_id and option durability data; the route can also answer with 201 Created.
  • Error (400): the payload is invalid or one booking prerequisite is missing.
  • Error (401): authentication is missing, invalid or expired.
  • Error (403): the caller is not allowed to create the booking in the current context.
  • Error (404): not documented in Swagger.
  • Error (409): the proposal, stock or pricing conditions are no longer valid.
  • Error (419): the selected flight is no longer available.
POST/v3/bookings
See more
2

Validate the booking with payment

Optional

This route allows you to validate a booking by making one or more payments. Use it once the payment information is complete and the booking is ready to move to its validated state.

Prerequisites

  • Reuse the booking_id returned by the booking creation step.
  • Send accept-language and x-api-key, plus authorization or x-agent-id when your integration context requires them.
  • Prepare a payment validation payload that references the booking and the payment information to apply.

Calling CURL

curl -X 'PATCH' \
  'https://api.clubmed.com/v2/bookings/0123456789' \
  -H 'accept: application/json' \
  -H 'accept-language: en-US' \
  -H 'authorization: Bearer YOUR_TOKEN' \
  -H 'x-agent-id: YOUR_AGENT_ID' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  --data-raw @booking-payment-validation.json

Example answer

HTTP/1.1 204 No Content

info: The successful contract does not return a payload, so read the booking again afterwards if the interface must confirm the refreshed payment state immediately.

Response codes

  • OK Response (200): not documented in Swagger. The successful contract is 204 No Content, so no response body is returned.
  • Error (400): the payload is invalid, incomplete or not valid JSON.
  • Error (401): authentication is missing, invalid or expired.
  • Error (404): not documented in Swagger.
PATCH/v2/bookings/{booking_id}
See more