Restrictions
Last updated
Was this helpful?
Last updated
Was this helpful?
An explanation of the algorithms used to support and .
Restrictions give Mews customers more control over their reservations, by preventing guests from making bookings that meet certain conditions. Restrictions can be applied to rates and space types, to control the way guests can book them. For example:
Use restrictions to implement a promotional rate which applies only to weekend bookings during July and August
Use restrictions to prevent guests from booking a room in a particular space type category (room type)
Additional help on restrictions
'How to' use case
API Operations
How to get service restrictions
How to add service restrictions
How to remove service restrictions
If the exceptions of the new restriction match the old restriction:
If the new interval is longer than the old one, a new restriction is created joining the two intervals.
If the new interval is shorter, no changes are made.
If the exceptions of the new restriction do not match the old restriction:
If the new interval does not overlap the old interval, the new restriction is added as usual.
The time interval for a specified restriction does not need to correspond to an existing restriction in the system, instead the API uses a splicing algorithm to work out how to divide up any existing restrictions to meet the specified time interval. For example:
Only restrictions created through the API are affected by these operations, not restrictions created by the user within Mews Operations. Similarly, if a user creates a restriction in Mews Operations, this will not affect restrictions created through the API. User restrictions and API restrictions are independent.
To retrieve information about restrictions, use . To add and remove restrictions, use and respectively.
Restrictions operations: Older operations and are deprecated. They are replaced by the more efficient and . Refer to the documentation for the individual operations for an explanation of the workings of these operations. Do not mix them, use Add restrictions with Delete restrictions, or Set restrictions with Clear restrictions. Note that as an API user you can only set and clear your own restrictions, independently of restrictions set within the user interface of Mews Operations, or indeed by other API users.
When using old API operation , if consecutive restrictions are sent with the same conditions and exceptions, no attempt is made by the system to merge the duplicate or overlapping restrictions. This means that there can be a large number of restrictions created per service, leading to sub-optimal performance. A quota limit of 150,000 was introduced. However, to mitigate the issue, API users are encouraged to migrate to new operation instead. For improved efficiency, merges multiple similar restrictions into a single restriction. Its sibling operation uses a splicing algorithm to work out how to divide up any existing restrictions to meet the specified time interval.
The following sections explain the algorithms used by these operations in more detail. These algorithms only apply to and .
When using , if a specified restriction already exists with the same conditions, or if multiple specified restrictions match in all properties but differ in time interval and follow each other chronologically, a merging algorithm is applied to combine them. This reduces the overall number of restrictions and improves system performance. The merging algorithm is as follows:
If the new interval overlaps the old interval, the old restriction will be before and after the new interval. Restrictions matching the old restriction are then added at the appropriate interval along with the new restriction.
The conditions specified in and must be met exactly. For example:
A bookable service has two restrictions A and B. Restriction A applies to resource category C1 and rate R1. Restriction B applies to resource category C1 and to all rates. If is called, specifying a restriction condition of resource category C1 but with no rate specified (this defaults to all rates), then only Restriction B is cleared, not Restriction A.
An existing restriction in the system A applies from 5th January to 25th January. As usual, time intervals are inclusive, meaning that the time interval includes both the 5th January and the 25th January. If the operation is called, specifying a restriction time interval of 10th January to 20th January, i.e. within the original restriction A, then the time interval of restriction A is split into three separate intervals. The original restriction A is deleted, and in its place new restriction B is created for the period of time from 5th January to 9th January inclusive, and new restriction C is created for the period of time from 21st January to 25th January. Thus the period 10th January to 20th January has been cleared, but without affecting other time periods.