`Booking/getBookings`

PMS v1 facade method. Pull every booking revision the property holds that is checkin-relevant and hasn't been acknowledged. The "revisions feed" your PMS polls in a loop to receive new + modified bookings.

Cutover status: legacy answers, port pending.

Request

GET https://api.quendoo.com/api/pms/v1/booking/getBookings
  ?api_key=…
  &type=new              # optional: 'new' | 'modified'
  &booking_id=161345     # optional: force a single booking revision (bypasses ack filter)

Query params

Param	Type	Required	Notes
`type`	`new` \| `modified`	no	Restricts the feed. Omitted = both. See below on what "new" vs "modified" mean.
`booking_id`	int	no	If set, returns that booking's current revision regardless of ack. Handy for re-fetching after a local database wipe.

Errors

Status	`message`	When
400	`Invalid value for the 'type' parameter!`	`type` set and not in `new`/`modified`.

How the feed works

Every call returns bookings that satisfy all of:

checkin_date >= today - 1 day (yesterday's arrivals still count — a booking's PMS lifecycle continues through check-out).
status != requested (unconfirmed / cart-abandoned bookings never leak into the PMS feed).
Bookings whose latest revision has not been acked yet — OR every booking, if you passed booking_id.

Two revisioning eras coexist:

Booking id ≥ 161300 — "new version". Legacy computes the revision id from the underlying content and returns it as revision_id + revision_number (monotonically increasing).
Booking id < 161300 — "old version". Legacy hashes the payload with MD5 to derive a revision_id, and always returns revision_number: 1.

Send the exact revision_id you receive back to ackBooking — matched byte-for-byte.

Response

{
  "data": [
    {
      "revision_id": "e5c1…",
      "revision_number": 3,
      "booking_id": 161345,
      "status": "modified",
      "checkin_date": "2027-02-14",
      "checkout_date": "2027-02-18",
      "num_adults": 2,
      "num_children": 0,
      "client": { "first_name": "…", "last_name": "…", "email": "…", "phone": "…" },
      "booking_items": [
        {
          "booking_item_id": 4211,
          "room_id": 4211,
          "rate_id": 985,
          "checkin_date": "2027-02-14",
          "checkout_date": "2027-02-18",
          "num_adults": 2,
          "price": 480.00,
          "currency": "EUR"
        }
      ]
    }
  ]
}

Notes on the shape

Order: id ASC, so you can page a large backlog by pulling repeatedly with a growing local cursor of the last-seen id.
Empty response is legal — no revisions to send.
Every revision received without an ack is re-sent on every poll until you ack it — the feed is idempotent by design.

Notes

Polling cadence: 30 seconds to 5 minutes is fine. The revisions cache is not billed per read; over-polling is more likely to trip a rate-limit budget than to help you catch a change earlier — legacy computes revisions on-the-fly on every read.
Do not conflate revision_number with a strong ordering across different bookings. It's monotonic per-booking.