Policies against abuses

Motivations

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 can even compromise the server side.

By the way, this happened several times. Results are rarely dramatic, but we want Wired to be always fast and responsive.

For this reason, we apply Anti-Flood policies, blocking clients which issue too many calls (abuses) and eventually compromising the usage of other providers.

Note

limits are very high. If you break them, rely on the fact that you’re surely badly using the service. For example, we allow 12 years (365 * 12 days) of updates for each room on 3 minutes. Notice also that limits are not provider-related, but property/room based.

This means that if you develop with intelligence, you don’t even need to take policies into consideration.

Anti Flood Policies

There are several kind of anti-abuses policies:

  • Token: there are limits on acquiring tokens and using them
  • Per function: almost all functions have limits. This means you can not call them more then N times in M seconds (N and M depending on the fucction).
  • Global: global number of calls
  • Room values: to prevent too many updates for the same room

Token limits

Please, while developing the authentication layer, keep in mind the following limits:

  • A token can be used, at maximum, for 60 operations
  • A token expires after 3600 seconds

Function limits

The following functions are limited. You can not call them so frequently:

Function Max Calls Time window (seconds)
fetch_rooms 120 86400
fetch_bookings_codes 24 3600
fetch_bookings 288 43200
rplan_rplans 240 86400
fetch_rooms_values 240 43200
fetch_rsrv_errors 12 3600
bcom_read_allotments 95 86400
get_plans 120 86400
rplan_get_rplan_values 240 43200

Global limits

Given a property, it’s not possible to launch more than 580 calls in 3600 seconds (operations related to this property).

Rooms values

For functions updating room values (like availability, prices, restrictions and so on), for example update_avail(), there is a maximum number of updatable days (for each room) depending on the time window.

Number of updated days Time window (seconds)
1460 1
4380 180
13140 3600
25550 43200
29200 86400
32850 172800
36500 259200

Note

A single call (for example update_avail), can update max 16000 days, this limit is not per room but it is calculated by the sum of all rooms selected.

What happens if you’re tagged as 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.

Note

Notice we work 7x7 and if this happens, we will help. Anyway, to prevent inconveniences, make sure to develop your client side by respecting limits.