Property/getPropertySettings
PMS v1 facade method. Read Quendoo's whole property snapshot in one call β property meta, rooms, rates, extras, meals, beds, payment methods, booking modules, OTA codes. The primary setup- time read: a PMS builds its mapping UI from this response.
Cutover status: legacy answers, port pending.
Request
GET https://api.quendoo.com/api/pms/v1/property/getPropertySettings
?api_key=β¦
&names=rooms,rates # optional β restrict to a subset. Omit for everything.
Query params
| Param | Type | Required | Notes |
|---|---|---|---|
names |
comma-separated string | no | Whitelist of top-level keys to include (see the full list below). Omit or leave empty to return every key. |
Every value in names is matched case-sensitively against the
top-level key names below. Unknown names are silently ignored.
Keys
| Name | Contents |
|---|---|
property |
{id, name} for the property itself. |
rooms |
Same shape as getRoomsDetails. |
rates |
Rate plans on the property. |
services |
Extras / add-ons the property sells. |
payment_methods |
Instances (Card X, Bank Y) available on this property. |
payment_methods_types |
Category catalogue (card, bank, cash, β¦). |
meal_plans |
BB, HB, FB, all-inclusive. |
bed_types |
Bed catalogue used by the room-layout picker. Read-only from the QC API. Custom per-room bed layouts remain a dashboard-only concern; per_person / per_occupancy rate plans no longer need a dashboard step β set sell_type on POST /rate_plans and the vocabulary auto-derives from each room's existing bed capacity (details). |
booking_modules |
Every booking module (booking_buttons) on the property, with id, name, url_key. The url_key is the bm_code in getBookingOffers. |
booking_ota_codes |
OTA reference codes attached to bookings β for a PMS that wants to display "came from Booking.com". |
Response
{
"data": {
"property": { "id": 4211, "name": "Hotel Panorama" },
"rooms": [ /* β¦see getRoomsDetailsβ¦ */ ],
"rates": [ { "id": 985, "name": "Standard B&B" } ],
"services": [ { "id": 12, "name": "Breakfast" } ],
"meal_plans": [ { "id": "BB", "name": "Bed & breakfast" } ],
"bed_types": [ { "id": "queen", "name": "Queen bed" } ],
"payment_methods": [ /* β¦ */ ],
"payment_methods_types": [ /* β¦ */ ],
"booking_modules": [
{ "id": 3204, "name": "Main website", "url_key": "hotelname" }
],
"booking_ota_codes": [
{ "code": "BDC", "name": "Booking.com" }
]
}
}
Only the keys named in names (or every key when names is
omitted) appear at the top level. data is always an object,
never an array, even for a single-key selection.
Errors
No errors are declared for this endpoint. If the property is not loadable at all the caller's api_key would already have failed authentication upstream.
Semantics
- Localisation: every
nameis at the request's active locale. - The endpoint is heavy β expect ~50β200 KB for a mid-size hotel,
much more for a chain. Prefer the
namesfilter after the first onboarding read. - Booking modules
url_keyis the exactbm_codeused bygetBookingOffers. A PMS that wants to prime search links needs this list.
Notes
- Reciprocal for pushing YOUR catalogue back:
postExternalPropertyData. - Setup-time call by design. Cache the response on your side and
refresh only when the hotelier tells you they added a room /
rate β legacy has no
Last-Modified/ETag.