Amendments
Note: This section offers an early preview of a new capability launching with selected partners. Content will be updated as the feature is finalised. Please reach out to your Partnerships Manager any time to align on the latest specifications.
General principle. The search-side endpoints stay the same as in the regular booking flow. To switch them into "amendment mode" you pass the existing booking_id. Once the customer has picked the change, you actually amend the booking in two calls: POST /amendments/create (propose) followed by PUT /amendments/confirm (commit).
The flow at a glance
Step | Endpoint | Purpose |
1. Search |
| Show the customer what is available for their existing booking: new trips, new ancillaries, new seats. Same shape as a regular search ā just scoped by |
2. Propose |
| Send the new offers the customer selected. rAPI returns an |
3. Confirm |
| Commit the amendment using the |
Step 1 ā Search, scoped to a booking
Any regular search endpoint becomes an amendment search by adding booking_id to the query. The offers returned are valid for an amendment of that booking and may include delta pricing. Seats will not respond with delta prices.
All examples below use the demo environment (api.demo.distribusion.com). Authentication via the Api-Key header is required on every request ā omitted from the snippets for brevity. Carrier and station codes (ZBUS, ZZSTN001ā¦) are placeholders.
1a. connections/find with search_bounds + booking_id
Same as a multi-bound search; booking_id just scopes the search.
{
"locale": "en",
"currency": "GBP",
"carrier_codes": ["ZBUS"],
"search_bounds": [
{
"departure_date": "2026-05-11",
"departure_location": {
"type": "stations",
"value": ["ZZSTN003"]
},
"arrival_location": {
"type": "stations",
"value": ["ZZSTN004"]
},
"is_requested": true
}
],
"passengers": [
{ "pax": 1, "max_age": 50 }
],
"booking_id": "qnrL4XjM4IUJ_sy_8GDDAg"
}
1b. connections/vacancy + booking_id (ancillary discovery)
Used to discover what ancillaries can be added to an existing booking.
{
"booking_id": "EpZaPpY29D3sRetM1ew_cA"
}
1c. seats/availability ā by selected offer(s) + booking_id
After a search returns offers, fetch the seat map for one or more of them. Same endpoint as in the booking flow; you just pass the offer ids and the booking_id.
Single offer
https://api.demo.distribusion.com/retailers/v4/seats/availability
?offers[][id]=83166253-e124-43b4-8b1e-185421ec8245|0
&booking_id=qnrL4XjM4IUJ_sy_8GDDAg
Multiple offers
https://api.demo.distribusion.com/retailers/v4/seats/availability
?offers[][id]=83166253-e124-43b4-8b1e-185421ec8245|0
&offers[][id]=e25a85d6-61d5-489f-9adb-307ecb24d2bf|6
&booking_id=qnrL4XjM4IUJ_sy_8GDDAg
Step 2: POST /ammendments/create
Send the offers the customer chose. The body always carries the booking_id being amended plus an offers[] array. Same offer shape as in reservations/create; the meaning of optional fields (passenger_ids, segment_ids, quantity, seat_selections) depends on the offer's coverage type
2a. Admission only (e.g. change date / change OD)
Single offer id, no passenger/segment scoping. Carrier-specific mandatory attributes may apply.
https://api.demo.distribusion.com/retailers/v4/amendments/create
{
"booking_id": "It-2QpvR-Xf4NOSSDOiSKA",
"offers": [
{
"id": "fee581cd-8e0b-442f-9e88-b7b40c64e822|1"
}
]
}
2b. Add a collective ancillary
Ancillary covers the whole booking ā no passenger_ids or segment_ids needed.
https://api.demo.distribusion.com/retailers/v4/amendments/create
{
"booking_id": "It-2QpvR-Xf4NOSSDOiSKA",
"offers": [
{
"id": "fee581cd-8e0b-442f-9e88-b7b40c64e822|1"
}
]
}
2c. Add a paid seat (separate add-on offer)
When seats are sold as a paid ancillary, each seat goes in its own add-on offer alongside the main admission offer.
https://api.demo.distribusion.com/retailers/v4/amendments/create
{
"booking_id": "It-2QpvR-Xf4NOSSDOiSKA",
"offers": [
{
"id": "main_admission_offer"
},
{
"id": "seat_add_on_offer_1",
"passenger_ids": ["pax_1"],
"seat_selections": [
{
"segment_id": "seg_1",
"passenger_id": "pax_1",
"seat_id": "v1-AAAA-a9f83b-1:12A-x7z911"
}
]
},
{
"id": "seat_add_on_offer_2",
"passenger_ids": ["pax_2"],
"seat_selections": [
{
"segment_id": "seg_1",
"passenger_id": "pax_2",
"seat_id": "v1-AAAA-a5g87n-1:13B-v4g876"
}
]
}
]
}
Step 3: PUT /ammendments/confirm
Commit the proposal returned by amendments/create. The body is small and identical regardless of what was amended.
https://api.demo.distribusion.com/retailers/v4/amendments/confirm
{
"amendment_id": "A7QPLB2K",
"execute_payment": false,
"terms_accepted": true,
"payment_method": "demand_note"
}
A confirmed amendment creates a new booking. PUT /amendments/confirm does not modify the original booking in place. It creates a new booking with a new booking_id and a new booking_number, and marks the original booking as amended. Both are returned in the confirm response: booking is the new, active booking; amended_booking is the original one that was superseded.
You must store the new booking_id and use it for all subsequent operations ā retrieving the booking, fetching tickets, cancelling, or making a further amendment. Calls made with the original booking_id will continue to resolve to the superseded booking.
The same applies to the booking_number shown to customers: after an amendment it changes, so any confirmation email, ticket or reference displayed to the passenger should be re-issued with the new number.
On this page
- Amendments