Tourism data is heavy and, sometimes, computations are far from being fast. So, a programmatic management produces sensible computational costs. In particular, a bad approach or a poor programming architecture on the client side may even compromise the server availability.
For this reason, we apply anti-flooding policies, blocking clients which issue too many calls (abuses) and eventually compromising the usage of other partners.
Limits are very high. If you break them, consider that you're surely badly using the service.
This means that if you develop wisely, you don't even need to take these policies into consideration.
Our anti-flooding policies are applied to different levels:
- Token: there are limits on acquiring a token and using it
- Per function: all functions have limits. This means you cannot call them more than N times in M seconds (N and M depending on the function).
- Per property: to prevent too many updates for the same property
- Global: global number of calls
The following functions are limited, you cannot call them so frequently. The maximum number of calls is related to each partner.
|GetAvailability||3600 / hour|
|GetRates||3600 / hour|
|GetProperties||3600 / hour|
|CreateProperties||24 / day|
For functions updating unit (room) values like availability, prices, restrictions, etc, there is a maximum number of updatable days for each unit, depending on the time window for a given function.
A single call (for example updateAvailability), can update max 3650 days, this limit is calculated per unit.
Given a partner, it's not possible to launch more than 360 calls per second.
What happens if you are tagged as a flooder?
Unless our staff manually resets your counters, you must wait a sufficient amount of time to use again the functions for which you exceeded limits. That's because limits are always related to a time window.