Update service availability
POST /api/connector/v1/services/updateAvailability
Updates the number of available resources in Resource category by a certain amount (relative adjustment). Note that availabilities are defined per time unit, so when the server receives the UTC interval, it first converts it to enterprise timezone and updates the availability on all time units that the interval intersects. It’s not allowed to update past availabilities outside of EditableHistoryInterval, future updates are allowed for up to 5 years.
Request Body
Section titled “Request Body ”object
Token identifying the client application.
Access token of the client application.
Name and version of the client application.
Unique identifier of the Service to update.
Availability updates.
object
Start of the time interval, expressed as the timestamp for the start of the first time unit, in UTC timezone ISO 8601 format.
Unique identifier of the Resource category whose availability to update.
Adjustment value to be applied on the interval, can be both positive and negative (relative adjustment, not an absolute number). If specified without Value parameter, removes all adjustments within the interval.
object
Value which is to be updated.
Unique identifier of the Availability block whose availability to update.
Collection of predicted occupancy of availability adjustments. Relates how many adjustments are assigned to each count of guests.
object
Predicted guest count that will be assigned to the Resource. The guest count must fit within the Resource Category maximum capacity.
Positive number of adjustments that are assigned to PersonCount. The sum of all UnitCount in PaxCounts should match the adjustment value applied to the interval.
Example
{ "ClientToken": "E0D439EE522F44368DC78E1BFB03710C-D24FB11DBE31D4621C4817E028D9E1D", "AccessToken": "C66EF7B239D24632943D115EDE9CB810-EA00F8FD8294692C940F6B5A8F9453D", "Client": "Sample Client 1.0.0", "ServiceId": "bd26d8db-86da-4f96-9efc-e5a4654a4a94", "AvailabilityUpdates": [ { "FirstTimeUnitStartUtc": "2020-10-05T23:00:00Z", "LastTimeUnitStartUtc": "2020-10-05T23:00:00Z", "AvailabilityBlockId": "23e85a44-d95a-4dcf-9f36-acb000b10abe", "ResourceCategoryId": "46bc1498-38cf-4d03-b144-aa69012f5d50", "UnitCountAdjustment": { "Value": 6 } }, { "FirstTimeUnitStartUtc": "2020-10-07T23:00:00Z", "LastTimeUnitStartUtc": "2020-10-08T23:00:00Z", "ResourceCategoryId": "46bc1498-38cf-4d03-b144-aa69012f5d50", "UnitCountAdjustment": {} } ]}Responses
Section titled “ Responses ”OK
object
Server has successfully fulfilled the request and there is no additional information to send back.
object
Error caused by the client app, e.g. in case of malformed request or invalid identifier of a resource. In most cases, such an error signifies a bug in the client app (consumer of the API).
object
Error caused by usage of invalid ClientToken, AccessToken, or you may not have the necessary permission to use the endpoint.
object
Server error that should be reported to the end user of the client app. Happens for example when the server-side validation fails or when a business-logic check is violated.
object
Error caused by heavy request that takes too long to process (typically tens of seconds). To get around this, request data in smaller batches. For more information, see Request timeouts
object
Error caused by too many requests sent in a given amount of time. Response contains Retry-After header indicating how long the user agent should wait before making a follow-up request. For more information, see Request limits.
object
Unexpected error on the Mews side. This may be due to a software fault. If such a situation occurs, the error will be logged and the development team notified, however you can raise an issue through GitHub on our documentation repository.