---
uuid: e2934fcc-c9f7-4383-8b18-8bab11d395ac
date_created: 2025-08-12T07:44:03.954Z
date_updated: 2026-04-03T17:59:14.227Z
seo_url: ducroire
category: Booking
tags: 
  - Booking
routes: 
  - POST /v3/bookings
  - PATCH /v2/bookings/{booking_id}
---

# Ducroire: finalize a booking with payment

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.

## Flow

```mermaid
flowchart LR
    step0["Create the booking from a proposal"]
    step1["Validate the booking with payment"]
    step0 --> step1
    classDef optional fill:transparent,stroke:#ffffff,color:#ffffff,stroke-width:1px,stroke-dasharray: 6\,4
    class step0 optional
    class step1 optional
```

## 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.

## 1 - Create the booking from a proposal

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

```bash
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

```json
{
  "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.

**Related route**: [POST https://api.clubmed.com//v3/bookings](https://api.clubmed.com/doc?search=POST%20%2Fv3%2Fbookings)

## 2 - Validate the booking with payment

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

```bash
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
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.

**Related route**: [PATCH https://api.clubmed.com//v2/bookings/{booking\_id}](https://api.clubmed.com/doc?search=PATCH%20%2Fv2%2Fbookings%2F%7Bbooking_id%7D)