Property/postExternalPropertyData
PMS v1 facade method. Register your PMS's own property snapshot
with Quendoo — the id + name of the property in your system, plus a
mapping table for every room type / rate type / service / meal /
bed type. Legacy uses this snapshot to resolve ext_room_id
references in other calls (updateAvailability, getAvailability,
etc.).
Setup-time call. Push it once at onboarding, then push again whenever your side's ids or labels change.
Cutover status: legacy answers, port pending.
Request
POST https://api.quendoo.com/api/pms/v1/property/postExternalPropertyData?api_key=…
Content-Type: application/json
{
"property": {
"id": "PMS-HOTEL-4211",
"name": "Hotel Panorama",
"mapping_data": {
"rooms_types": [
{ "id": "PMS-STANDARD-QUEEN", "name": "Standard Queen" },
{ "id": "PMS-DELUXE-KING", "name": "Deluxe King" }
],
"rates_types": [
{ "id": "PMS-RATE-BAR", "name": "Best Available Rate" }
],
"services_types": [
{ "id": "PMS-EXTRA-BREAKFAST", "name": "Breakfast" }
],
"meals_types": [
{ "id": "PMS-MEAL-BB", "name": "Bed & breakfast" }
],
"beds_types": [
{ "id": "PMS-BED-QUEEN", "name": "Queen bed" }
]
}
}
}
Payload
Top-level property is required with the following fields:
| Field | Type | Required | Notes |
|---|---|---|---|
id |
string | yes | Your PMS's own id for this property. Free-form. |
name |
string | yes | Human-readable property name. |
mapping_data |
object | yes | Required object with the five mapping arrays below (all five are read; missing / empty ones are stored as empty). |
Every mapping array is a list of {id, name} objects — your PMS's
id + label for that category. Legacy stores them verbatim under
the api_user's row in property_mapping_data, without validating
that each id resolves to a Quendoo entity. Reconciliation is
Quendoo-side, done manually in the dashboard's PMS-mapping UI.
| Array | Represents |
|---|---|
rooms_types |
Your room-type catalogue. IDs referenced by ext_room_id in updateAvailability / getAvailability. |
rates_types |
Rate plans. |
services_types |
Extra services (add-ons). |
meals_types |
Meal plans (BB, HB, FB, …). |
beds_types |
Bed types (single, queen, sofa-bed, …). |
Errors
| Status | message |
When |
|---|---|---|
| 400 | Bad post request data! |
Any of property / property.id / property.name / property.mapping_data is missing or empty. |
Response
{ "message": "Success" }
Semantics
- Every push fully replaces the caller's stored snapshot —
legacy doesn't merge on
id. Send the whole catalogue every time; omitting a room here removes it from the mapping. - The reciprocal — reading Quendoo's canonical catalogue for
manual mapping in your PMS's UI — is
getPropertySettings. - Only the caller's own api_user row is touched; two PMSs on the same property maintain independent snapshots.
Notes
- Push after every catalogue change on your side (new room type, renamed rate). The reconciliation UI in Quendoo will surface the new/renamed rows next time an operator opens it.
- The payload can be large for chain properties. The rate limit still applies; batch a many-property update as serial calls rather than one giant payload — legacy processes one property per call.