This section outlines rules that must be followed when using the Booking.com Demand API.
API users and partners who do not adhere to these rules or who abuse Booking.com servers may have their API privileges revoked. This can include both the availability and static content endpoints. Partners using the **processBooking** endpoint will also lose the ability to make reservations with the API. Booking.com does not accept any liability for loss of revenue caused by disabling API access for abuse reasons.
## Maximum API connections
- 20 simultaneous connections per API user are allowed.
- An automated process will disable API access if a user exceeds a certain number of connections within one minute. The limit should never be encountered via normal API use and cannot be manually reset or increased.
## Price comparison
In this context, "price comparison" refers to the comparison of accommodation prices made available from two or more online booking platforms. Where an affiliate wishes to use Booking.com properties for the purposes of price comparison, they are not permitted to use any of the content provided by Booking.com or made available through the Booking.com website. This includes the property description, photos, details of facilities, policies and more. As such, the affiliate will be required to use its own content to appropriately describe each property.
## No data forwarding
Data forwarding or forward distribution is strictly forbidden. When an affiliate sends data from the Booking.com API to another company that is not affiliated with or part of the company contracted to in the affiliate agreement, this is considered data forwarding or forward distribution. This includes selling content or giving it away for free.
## Caching of availability content or heavy caching of static content
Some caching is always needed for static content, but these types of content (for example hotel data) will not change frequently. For these cases see the recommended update frequency.
Partners are not allowed to cache availability or prices. This is to ensure the presented information is always as accurate as possible. With the huge number of properties on Booking.com, availability and pricing changes very rapidly, so any cache of this data will be inaccurate very quickly.
## Do not alter the property description
The content provided for the property description has been carefully curated by Booking.com to make sure it truly represents the property and its features. Changing any of this text is strictly forbidden as it may misrepresent the property.
## Do not change prices
The price returned in availability endpoints is the actual price the property has entered into our system and the price that bookers will pay. Changing the display of this price for any reason is strictly forbidden.
## Do not alter or download property images
Property photos come directly from the property, enabling the booker to see exactly what and where they are going to stay. This is paramount when it comes to conversion and cancellation. If these images are tampered with or changed in any way it could mislead the user, and is therefore strictly forbidden.
Partners must store the URL to hotel images for use in HTML IMG tags. Downloading the image files themselves is not permitted.
## Responsibility to show current data
API users who are caching content are responsible for keeping the data current. This is to ensure content is updated or removed in cases where Booking.com may no longer have permission to use it, or when content is no longer valid. Failure to keep data current may result in complaints being brought against partners. Booking.com cannot take any responsibility for complaints and third-party claims about outdated content.
## Closed properties
If a property has been flagged as closed, partners must remove all related data from their websites, apps, and/or databases.