`Booking/ackBooking`

PMS v1 facade method. Acknowledge a booking revision, optionally with your PMS's reservation ids per item. An acked revision drops off the getBookings feed.

Cutover status: legacy answers, port pending.

Request

POST https://api.quendoo.com/api/pms/v1/booking/ackBooking?api_key=…
Content-Type: application/json

{
  "booking_id": 161345,
  "revision_id": "e5c1…",
  "booking_items": [
    {
      "booking_item_id": 4211,
      "ext_reservation_id": "PMS-RES-98761",
      "room_number": "217",
      "self_checkin_code": "5810"
    }
  ]
}

Payload

Field	Type	Required	Notes
`booking_id`	int	yes	The booking whose revision you're acking.
`revision_id`	string	yes	The exact revision id from `getBookings`.
`booking_items[]`	array	no	If provided, every entry marks that booking item as PMS-synced and stores your ids/annotations. Omit to ack without item-level detail.
`booking_items[].booking_item_id`	int	yes on entry	Legacy booking item id.
`booking_items[].ext_reservation_id`	string	yes on entry	Your PMS's reservation id — what the front desk sees. Stored on the booking item.
`booking_items[].room_number`	string	no	Physical room number if already assigned.
`booking_items[].self_checkin_code`	string	no	For hotels that email the guest a keypad code.

Errors

Status	`message`	When
400	`Bad request data!`	`booking_id` or `revision_id` missing.
400	`The ack was already sent!`	This revision already carries an `ack_date`. Re-acking is not a no-op; it errors.
400	`Missing booking_items[].booking_item_id and/or booking_items[].ext_reservation_id!`	An entry in `booking_items` is missing one of the two required fields.
404	`Missing booking revision!`	The `booking_id` + `revision_id` pair does not match a row `getBookings` handed you.
404	`Missing booking!`	Booking id exists as a revision but the underlying booking was deleted between poll and ack (extremely rare).
404	`Missing booking item!`	An entry references a `booking_item_id` that's not on this booking.

Response

{ "message": "Success" }

Semantics

Acking one revision does NOT ack any earlier revisions — every revision you're handed must be acked individually. In practice that only matters when you skipped a poll and two revisions have accumulated; the newer one carries the current state and acking it is what you want, but the older one stays in the feed until it's acked too. Ack in order to keep the feed clean.
Acking with a booking_items[] array writes ext_reservation_id and any provided annotations onto the item. Skipping the array acks the revision only — the item's PMS ids stay whatever they were.
pms_status on each item goes to sync_ok; a subsequent ack from a different PMS on the same item is rejected — legacy binds an item to the first PMS that touched it.

Notes

The endpoint is quiet by design: {"message":"Success"} and nothing else on the wire.
Rate-limit budget: acks share the writes bucket. A backlog of 200 acks is a 200-call burst — pace them by the X-RateLimit-* headers.