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_values	192	43200
rplan_get_rplan_values	192	43200
wired_rplan_get_rplan_values	192	43200
fetch_bookings	230	43200
fetch_bookings_codes	19	3600
fetch_rooms	192	86400
fetch_single_room	150	86400
get_plans	96	86400
rplan_rplans	192	86400
fetch_ccard	32	3600
bcom_read_allotments	76	86400
fetch_rsrv_errors	9	3600
update_plan_periods	160	3600
update_avail	160	3600

Global limits

Given a property, it’s not possible to launch more than 480 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.