{
"openapi": "3.0.1",
"info": {
"title": "Facilities API",
"description": "Manage facilities at both the property- and room-level.\\n\nBooking.com supports adding or assigning a variety of different facilities at the property- or room-level.\nSpecify the facility ID along with any required parameters to assign a facility.\\n\\nFacilities are of the following types:\n
Single-instance facilities: You can assign these facilities only once to a property or a room.\nAn example of a single-instance facility is: room service. There are two types of single-instance facilities:\n
Single-instance facilities that can be toggled on or off.
Single-instance facilities supporting optional parameters:\nAllows you to specify more details about the facility
Multi-instance facilities:\nYou can assign multiple facilities of this type to a property.\nWhen adding multi-instance facilities you must provide additional details to add to a property or a room.\nExamples of multi-instance facilities are: Restaurant, Swimming pool and Parking.
\n",
"contact": {
"name": "Connectivity Team",
"url": "https://connect.booking.com",
"email": "connectivity@booking.com"
},
"version": "1.0"
},
"servers": [
{
"url": "https://supply-xml.booking.com/facilities-api/",
"description": "Test using live endpoint"
}
],
"tags": [
{
"name": "About Try it",
"description": "Learn how to effectively use the Try it feature in the Facilities API documentation.\n\nUse the **Try it** feature to send test request examples to the API endpoints directly from the developer portal and depending on the selected environment either see static, pre-built responses or dynamic responses from a test property.\n\n## Environment\n\nYou can select between two different environments (top right corner in the UI):\n\n**Test static response** (default):\n- Helps to understand the response data schema\n- Recommended for all write operations (POST, PUT, DELETE)\n- Environment for testing without affecting live/test data\n\n**Test live endpoint**:\n- Make sure to use only test properties.\n- Changes will affect your test property data\n- Requires valid credentials\n- Same API structure as production\n\n## Request\n\nUsing the UI, toggle between **Edit** and **Preview** tabs to see the values applied to the path or query placeholders (if there are any). You can also click on any unresolved placeholders to add a value or edit an existing placeholder value.\n\nThe portal loads the default request body. Where the specification supports multiple request body examples (for example: Rooms API POST endpoint), you can choose a different request body from the drop-down list.\n\nSome helpful pointers before running a request:\n\n- **Authentication** (when using live endpoint): Configure your authentication headers\n - API Key or OAuth token as required. Use the **Environments** tab.\n - Make sure to manage separate machine accounts for test vs. properties in production.\n - Ensure credentials match your selected environment.\n\n- **Parameters**: Fill in required parameters\n - Path parameters (like `propertyId`)\n - Query parameters (like `language_code`)\n - Request body for `POST/PUT` operations\n\n- **Execute**: Click **Send** to send the request\n - The request is sent to the selected environment\n - When sending requests to the live endpoint, real HTTP request is made to the API\n\n## Response\n\nThe Try it feature provides comprehensive response information to the extent supported by the Open API specification:\n\n### Status code\n- **2xx**: Success responses (200)\n- **4xx**: Client errors (400 Bad Request, 401 Unauthorized, 404 Not Found)\n- **5xx**: Server errors (500 Internal Server Error)\n\n### Response body\n- JSON formatted response data\n\nIf the returned response, by default, is unformatted, select the supported Response body format in the UI.\n\n### Response headers\n- Content-Type, Content-Length.\n\n## Environments\n\nThe **Environments** tab allows you to create variables specific to the environment. For example, you can add a variable to hold the value of the `property-id` placeholder. The portal inserts the respective value depending on the environment at the time of sending the request.\n\n### Variables\n\nMost of the endpoints (especially POST/PUT/DELETE) require you to add a path or query parameter before sending the request. The Open API specification marks these parameters with placeholder tags. For example, {{`property_id`}}. You can use the **Environments** tab to manage the values for these placeholders as variables.\n\n#### Path parameters\n- **Required**: Must be provided to make the request\n- **Type validation**: Ensures correct data types (integer, string, etc.)\n- **Example**: `propertyId` in `/facilities-api/properties/{propertyId}`\n\n#### Query parameters\n- **Optional**: Usually have default values\n- **Example**: `language_code` with `en-us` as the default value\n\n#### Request body\n- **Schema validation**: Follows OpenAPI schema definitions\n- **Example data**: Prepopulated with sample values\n\n## Best practices\n\nThis section provides some basic practice guidelines.\n\n### Authentication\n\n- Always use separate machine accounts for test properties vs. properties in production.\n- When testing with production endpoint, make sure to use only test properties.\n\n### For Read operations (GET)\n- Safe to test in any environment\n- Use valid IDs that exist in your system\n- Check response structure for integration planning\n\n### For Write operations (POST, PUT)\n- **Always use static response first**\n- Verify request payload structure\n- Check response for success confirmation\n- Test error scenarios with invalid data\n\n### For Delete operations (DELETE)\n- **Use static response environment only**\n- Understand the operation is irreversible\n- Have backup data when testing using test properties\n\n## Troubleshooting\n\n### Common issues\n\n**401 Unauthorized**\n- Check authentication credentials\n- Verify API key is valid and not expired\n- Ensure credentials match the selected environment\n\n**400 Bad Request**\n- Validate request payload against schema\n- Check required fields are provided\n- Verify data types match specification\n\n**404 Not Found**\n- Confirm the resource ID exists\n- Check the endpoint URL is correct\n- Verify you have access to the resource\n\n### Getting help\n\nIf you encounter issues:\n1. Check the response error message for details\n2. Verify your request matches the API specification\n3. Contact the Connectivity Team for support\n\n---\n\n*This documentation applies to all endpoints in the Facilities API. The Try it feature provides a consistent testing experience across all operations.*"
},
{
"name": "Manage property facilities",
"description": "Use the GET and the PUT endpoints to:\n
Retrieve property-level facilities details
\n
Add, modify or delete property-level facilities details
Add single-instance facilities
\n
Add multi-instance facilities
\n"
},
{
"name": "Manage room facilities",
"description": "Use the GET and the PUT endpoints to:\n
Retrieve room facilities set for a property.
Add, modify or delete room facilities.
\n"
},
{
"name": "Manage bathrooms",
"description": "Use the GET and the PUT endpoints to:\n
Retrieve room bathroom configuration
\n
Add, modify or delete room-level bathroom information
\n"
},
{
"name": "Meta data endpoint",
"description": "
Retrieve the latest facility definitions.
\n
\n
Get the list of all supported facilities
\n
To get the details of a property-level facility: Look for a matching name under the facility_name in the response.\nTo add this facility, you must specify the facility_id.\nProperty-level facilities are listed under the property_facility_metas in the meta endpoint response.
\n
To get the details of the room-level facility: Look for a matching name under the room_facility_name in the response.\nTo add the facility, you must specify the room_facility_id.\nRoom-level facilities are listed under the room_facility_metas in the meta endpoint response.
\n
\n
\n
Details of the facilities such as ID, OTA code and any optional parameters.