EDistribution API

Amendments#

Change a live booking — dates, occupancy, meals, services, guests — in place. The booking keeps its id, and its ledger charge moves to the new value.

PATCH /v1/bookings/{bookingId}.

Absent means unchanged#

Every field is optional, and omitting one leaves it alone.

For the list fields — meals, vas, guests — a supplied value is the complete new list, not an addition. Sending one meal replaces the selection with that one meal.

That is the distinction to be careful with: omitting meals keeps the existing selection; sending [] clears it. They are different requests, and a client that serialises absent fields as null or [] will silently wipe things.

Move the dates only
curl -X PATCH "$BASE/v1/bookings/bkg_20Etl54TyD" \
  -u "$ELIVAAS_API_KEY:" \
  -H 'Content-Type: application/json' \
  -d '{"checkIn":"2026-08-17","checkOut":"2026-08-20"}'
Clear all meals
curl -X PATCH "$BASE/v1/bookings/bkg_20Etl54TyD" \
  -u "$ELIVAAS_API_KEY:" \
  -H 'Content-Type: application/json' \
  -d '{"meals":[]}'
checkIn / checkOutstring<date>

New stay dates. Omit to keep the current ones.

adults / children / infantsinteger

New occupancy. Omit to keep current.

mealsarray

The complete meal selection the amended stay should have. Omit to leave untouched; [] clears.

vasarray

The complete value-added-service selection. Same semantics as meals.

guestsarray

The complete guest list, lead guest first. Omit to leave untouched.

What happens to the money#

An amendment moves the booking's existing charge to the new total. It does not post a second charge for an increase or a credit for a decrease — there is one CHARGE per booking for its whole life. See the ledger.

Rate drift#

The delta you get is not always the delta you asked for, and this catches people out.

Repricing an amended stay reprices the whole stay at today's rates, not just the nights you changed. If rates have moved since the booking, the unchanged nights move with them.

So the total change has two parts: what your amendment actually altered, and what drifted underneath it. A ₹14,160 booking whose dates shift by a week can land at ₹21,240 even though you only moved the dates.

See the figures before you commit. POST /v1/bookings/{bookingId}/amendments previews the amendment and returns the same breakdown without applying it.

Preview first
curl -X POST "$BASE/v1/bookings/bkg_20Etl54TyD/amendments" \
  -u "$ELIVAAS_API_KEY:" \
  -H 'Content-Type: application/json' \
  -d &#39;{"checkIn":"2026-08-17","checkOut":"2026-08-20"}'

The two components are reported separately so you can tell them apart, and they always reconcile:

code
delta = amendmentDelta + rateDriftAbsorbed

If rateDriftAbsorbed is large, the honest thing to show a customer is the new total — not the delta you expected from the change alone.

What can be amended#

An amendment is refused when the booking is cancelled, checked in, or past checkout. It is also refused once the booking has been billed on an issued invoice.

Concurrency#

Two amendments racing on one booking will not both apply. The loser is rejected rather than layered on top of a figure it never saw — so a change is never applied against a stale baseline.

If you get a conflict, re-read the booking, recompute what you want, and try again.

Events#

A successful amendment emits booking.amended. It is the one callback event that repeats — a booking amended three times produces three of them.

Order your handling by occurredAt rather than arrival time, and key deduplication on X-Elivaas-Event-Id, not on the booking id.

Next#

Cancellations — when a change is not enough.