`Availability/updateAvailability`

PMS v1 facade method. Push a room's inventory (qty offered and/or open-for-sale flag) for a date or a date range. The write that keeps a channel manager in sync minute-to-minute.

Cutover status: legacy answers, port pending. Behaviour below describes what legacy does today and what QC will byte-match.

Request

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

{
  "values": [
    { "room_id": 4211, "date": "2027-02-14", "qty": 3, "opened": true },
    { "ext_room_id": "PMS-STANDARD-QUEEN", "date_from": "2027-02-15", "date_to": "2027-02-28", "closed": true }
  ]
}

Payload

Top-level values is required and must be a non-empty array. Every entry updates one room over one date or one date range.

Field	Type	Required	Notes
`room_id`	int	exactly one of `room_id` / `ext_room_id`	Legacy `property_rooms.id`.
`ext_room_id`	string	exactly one of `room_id` / `ext_room_id`	Your PMS's own id, resolved via `PropertyMapping::getMappedRoomByExtId`.
`date`	`YYYY-MM-DD`	one of `date` OR (`date_from` + `date_to`)	Single-day update.
`date_from`	`YYYY-MM-DD`	pair with `date_to`	Range start (inclusive).
`date_to`	`YYYY-MM-DD`	pair with `date_from`	Range end (inclusive).
`qty`	int ≥ 0	one of `qty` OR `opened`/`closed`	New qty offered. Legacy stores it with `add_qty_booked` semantics — see below.
`opened`	bool	one of `qty` OR `opened`/`closed`	`true` opens the room for sale.
`closed`	bool	one of `qty` OR `opened`/`closed`	`!closed` is stored. Provided as a legacy alias.

Bounds

Date range: date_from - 1 day … date_from + 2 years. Rows outside are silently skipped — they don't error, they no-op.
Rows are trimmed to the bounds when they straddle them (a range starting today going to +3 years is trimmed to today…+2 years).

`add_qty_booked` — what `qty` actually stores

Legacy stores qty_offered = qty + qty_booked on every set — i.e. you push "sellable capacity", not "physical capacity". If a room sold 2 out of 5 physical rooms and you push qty=3, the calendar row ends at 5 total, 2 booked, 3 offered. A PMS that treats qty as sellable ships that number verbatim.

Errors

Status	`message`	When
400	`Bad request data! Wrong format of the post structure (missing 'values' structure - check documentation)!`	`values` missing / not-array / empty.
400	`Invalid qty (qty can't be < 0) for: <dump>`	`qty` is negative.
400	`Missing parameters qty and/or is_opened for: <dump>`	Neither `qty` nor `opened`/`closed` on this row.
400	`Both parameters 'room_id', 'ext_room_id' can't be set at the same time!<dump>`	Both id fields given.
400	`Missing room_id for: <dump>`	Neither id given.
400	`Not found property room_id for: <dump>`	`room_id` isn't on this property.
400	`Invalid date format (must be 'YYYY-MM-DD') for: <dump>`	Bad date.
400	`Invalid date_from/date_to format (must be 'YYYY-MM-DD') for: <dump>`	Bad range date, or `date_from > date_to`.
400	`Missing date or date_from/date_to for: <dump>`	No date fields at all.
400	`Invalid params for: <dump>`	The row was assembled but fails `avcItem::isValid()` after trimming.
404	`Can't find room id for the given ext room id for: <dump>`	`ext_room_id` isn't mapped for this api_user.

<dump> is a print_r of the offending row — legacy leaks payload into the error message on purpose; the QC port keeps the same string so partners' log-scrapers keep matching.

Response

{ "message": "Success" }

The whole batch is atomic in effect only — legacy applies rows one-by-one; a mid-batch error rejects with the row's dump but any row that already applied stays applied. Send an idempotency-friendly batch, i.e. one that's safe to re-post.

Notes

Set-time on every calendar row is fixed at 05:00 property-local regardless of what the request sends.
The endpoint is quiet by design: successful writes return one line. No echoed values, no counts, no timestamps.
Do not race two updateAvailability calls for the same (room, date) — legacy has no per-row lock and the second write wins on wall-clock order.

Availability/updateAvailability