Method to externally manage room availability

Table of Contents
  1. URL Endpoint
  2. Request Body
  3. Examples



URL Endpoint

/manage/availability

Warning

This method is only accessible using a Hotelier API account.

This method is only accessible using a POST request.

To get a response in JSON make sure you are also sending the Accept: application/json header.




Request Body

Post a JSON document with the following structure:

{
	"ROOMCODE": [
		{
			"from":ISO 8601, // Starting date for period updates, mutually exclusive with "date"
			"to":ISO 8601, // Ending date for period update, mutually exclusive with "date"
			"date":ISO 8601, // Single-date update, mutually exclusive with "from" and "to"
			"weekdays":STRING[], // Specific days of week to apply the update ( Sun, Mon, Tue, Wed, Thu, Fri, Sat )
			"allot":INTEGER, // Allotment for date or date-period ( optional )
			"stopsell":BOOLEAN, // 1=Stop Sell Restriction, 0=No restriction ( optional )
			"minstay":INTEGER, // Minimum stay in days ( optional )
			"maxstay":INTEGER, // Maximum stay in days ( optional, to remove restriction send 0 )
			"checkin":BOOLEAN // 1=Check-in is allowed, 0=Check-in not allowed ( optional )
			"checkout":BOOLEAN // 1=Check-out is allowed, 0=Check-out not allowed ( optional )
		}
	]
}

Notice

Request body must be in valid JSON format.

Updates are made only if the entire request body is successfully parsed and validated.

Notice

Updates are transactional, that means that the entire batch of updates included in the request will either succeed or fail in its entirety. We guarantee that no request can partial mutate WebHotelier state.

You can use the Availability Feed method to validate WebHotelier state against your data.

Requirements

  • For newly initialized dates, allotment MUST be present in the first request, either standalone or in combination with other values. Trying to update stopsell, min/max stay, etc. without specifying allot will result in an error. After a date has been initialized, then it is safe to only update any other value.
  • ALWAYS pack updates in a single request. Each HTTP request may have a big overhead so sending all updates in a single request is critical, even if the updates are for different room types.
  • Always use ranged updates when applicable ( from/to instead of date ). Adjacent dates with the same payload should ALWAYS be converted to a ranged update.

Caution

We closely monitor all updates going in WebHotelier.
If best practices are not followed it may result in the banning of your API account or your IP address.




Examples

The following examples illustrate common use cases and possible combinations:


1. Single Day Availability Update

{
	"DBL": [{"date":"2017-05-13","allot":5}]
}

2. Period Availability Update

{
	"DBL": [{"from":"2017-05-20","to":"2017-05-27","allot":7}]
}

3. Mixed Availability Updates

{
	"DBL": [
		{"date":"2017-05-13,"allot":5},
		{"from":"2017-05-20","to":"2017-05-27","allot":7}
	]
}

4. Multiple room type availability updates in a single request

{
	"SGL": [
		{"date":"2017-05-13,"allot":8},
		{"from":"2017-05-20","to":"2017-05-27","allot":9}
	],
	"DBL": [
		{"date":"2017-05-13,"allot":15},
		{"from":"2017-05-20","to":"2017-05-27","allot":20}
	],
	"TRP": [
		{"date":"2017-05-13,"allot":5},
		{"from":"2017-05-20","to":"2017-05-27","allot":7}
	]
}

5. Stop Sell ( availability is not changed )

{
	"DBL": [{"from":"2017-05-20","to":"2017-05-27","stopsell":1}]
}

6. Different options can be combined in a single request

{
	"DBL": [{"from":"2017-05-20","to":"2017-05-27","stopsell":0,"checkin":0,"minstay":7}]
}

7. Mixed example

{
	"SGL": [
		{"from":"2017-05-20","to":"2017-05-27","stopsell":0,"checkin":0,"minstay":7}
		{"date":"2017-05-13","stopsell":1,"allot":0}
	],
	"DBL": [
		{"from":"2017-05-20","to":"2017-05-27","stopsell":0,"checkin":1,"minstay":1}
		{"date":"2017-05-13","stopsell":0,"allot":6}
	]
}

8. Specific weekdays update

{
	"DBL": [{"from":"2017-05-20","to":"2017-05-27","allot":7,"weekdays":["Sat", "Sun"]}]
}