Booking.com Facilities API

openapi: 3.0.1
info:
  title: Facilities API
  description: 'Manage facilities at both the property- and room-level.<br>

    Booking.com supports adding or assigning a variety of different facilities at the property- or room-level.

    Specify the facility ID along with any required parameters to assign a facility.<br><br>Facilities are of the following
    types:

    <ul><li>Single-instance facilities: You can assign these facilities only once to a property or a room.

    An example of a single-instance facility is: room service. There are two types of single-instance facilities:

    <ul><li>Single-instance facilities that can be toggled on or off.</li><li>Single-instance facilities supporting optional
    parameters:

    Allows you to specify more details about the facility</li></ul><li>Multi-instance facilities:

    You can assign multiple facilities of this type to a property.

    When adding multi-instance facilities you must provide additional details to add to a property or a room.

    Examples of multi-instance facilities are: Restaurant, Swimming pool and Parking.</li></ul>

    '
  contact:
    name: Connectivity Team
    url: https://connect.booking.com
    email: connectivity@booking.com
  version: '1.0'
servers:
- url: https://supply-xml.booking.com/
  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 sample requests to API endpoints directly from the developer portal. In the **Mock (schema only)** environment,\
    \ Try it returns schema-driven mock responses or pre-built example responses. In the **Production** environment, it sends\
    \ the request to the live API and returns dynamic responses from your selected test property.\n\n## Environment\n\nYou\
    \ can select between two different environments (top right corner in the UI):\n\n**Mock (schema only)** (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\nYou can 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 Mock (schema only) environment 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- **Preferable to use\
    \ Mock (schema only) 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:

    <ul><li>Retrieve property-level facilities details</li>

    <li>Add, modify or delete property-level facilities details<ul><li>Add single-instance facilities</li>

    <li>Add multi-instance facilities</li></ul></li></ul>

    '
- name: Manage room facilities
  description: 'Use the GET and the PUT endpoints to:

    <ul><li>Retrieve room facilities set for a property.</li><li>Add, modify or delete room facilities.</li></ul>

    '
- name: Manage bathrooms
  description: 'Use the GET and the PUT endpoints to:

    <ul><li>Retrieve room bathroom configuration</li>

    <li>Add, modify or delete room-level bathroom information</li></ul>

    '
- name: Meta data endpoint
  description: '<p>Retrieve the latest facility definitions.</p>

    <ul>

    <li>Get the list of all supported facilities<ul>

    <li>To get the details of a property-level facility: Look for a matching name under the facility_name in the response.

    To add this facility, you must specify the facility_id.

    Property-level facilities are listed under the property_facility_metas in the meta endpoint response.</li>

    <li>To get the details of the room-level facility: Look for a matching name under the room_facility_name in the response.

    To add the facility, you must specify the room_facility_id.

    Room-level facilities are listed under the room_facility_metas in the meta endpoint response.</li>

    </ul>

    </li>

    <li>Details of the facilities such as ID, OTA code and any optional parameters.</li>

    </ul>

    '
x-tagGroups:
- name: API Endpoints
  tags:
  - Manage property facilities
  - Manage room facilities
  - Manage bathrooms
  - Meta data endpoint
- name: Documentation
  tags:


# --- truncated at 32 KB (93 KB total) ---
# Full source: https://raw.githubusercontent.com/api-evangelist/booking-com/refs/heads/main/openapi/booking-com-facilities-api-openapi.yml