Websockets will allow you to retrieve real-time data or prevent you from polling too many data
When should I use Websockets ?
When polling would be too resource consuming or not enough "real-time", websockets should be used. After successful connection, the client will start receiving messages depending on configuration of the Connector integration in Commander. You will find all the extend of our Websockets solution in our documentation.
For example : when pulling too many times reservations/getAll as real-time information will be needed. You can find our requests limits in our guide.
Can I test Websockets in Demo ?
It is indeed possible to configure and test WebSockets in the Mews Demo environment.
1- Testing with credentials
The simplest way to test WebSocket connections would be to use a browser extension. For example, the Browser WebSocket Client Chrome extension.
Just as you you will need a pair of Access and Client tokens to to make various API calls to Mews, you will need the same to authenticate a WebSocket connection. The Client token corresponds to that of the generic "Are you ready to integrate with Mews?" integration in Mews Demo.
For the purposes of testing, you do NOT need to add a new integration. Instead, please use the pair of tokens listed in the Authentication section of our Connector API documentation.
Follow the URL format prescribed in the Endpoint part of the WebSockets documentation to set up the connection.
Maintaining the connection
Mews recommends that the integration sends a WebSocket Ping request to Mews at regular intervals (e.g. every 5 minutes) to monitor the connection. If the Ping request fails, the integration interface should be restarted or try to re-establish a connection.
Types of event you can test
Depending on what the integration does, you may wish to test any of the four types of WebSocket events listed in the API Documentation.
Simply make any changes to the relevant items in Mews (e.g. reservation, space, rate price, etc) in order to trigger an event.
What it looks like in the production environment
When your integration has been successfully certified with Mews Marketplace, you will receive one unique Client Token for your integration, for the production environment, this is to be paired with the Access Token (which differs from property to property)
For each property that adds an integration to their Marketplace subscriptions, a new Access Token will be generated, and it is unique to the specific property. You can then use the pair of Access/Client tokens to establish a websocket connection between the property's Mews environment and your integration interface.
(Guide for properties on how to find their Access Tokens)
2- Testing without credentials
If you are mainly interested in the type and content of the Websocket notification that will be generated by a particular event in Mews, you can test WebSockets without needing to configure a connection.
- Go to dashboard and open the devs tools for Chrome (F12), click on "Network" and then select "WS", reload the page if needed and you will see the WebSocket in the list:
- Click on it and select the tab "Messages", from there you will be able to see all the WebSocket events:
- When you make an action that triggers an event, you will see it listed there as
"Type":"Events", and you can click on it to see the details for it (in this example you can see how the resource was changed to "Inspected":
If you are able to connect to the websocket but do not see any events coming in, simply make any action in the Mews demo hotel you are connected to, to trigger an event. E.g. create a reservation, check in a reservation, make a space as Inspected, etc.
Can we give recommendations on Websockets implementation ?
One WebSocket instance per Access Token
Integration partner should create separate instances of websocket client for each access token.
Add time buffer between connect & reconnect
Helpful for if the WebSocket reconnect keeps failing.
Could you try to add some time buffer between the connect and reconnect?
In our Mews Connector application, which also uses WebSockets, we start with a random interval between 5 to 30 seconds, and then with each unsuccessful reconnect we add another 5-30 seconds on top of that until the maximum interval of 2 minutes is reached. Then once a successful connection is established, the app resets the reconnect interval back to the base value.
The connection could drop when we deploy something to the production environment, so waiting a few seconds up to minutes before reconnecting could be something to try.
We are developing Webhook support for the events that are currently supported by WebSockets, so hopefully we'll be able to bring you a more stable connection soon.
Do we always send "close" event when the connection is closed ?
When we are the ones explicitly closing then yes, cases are for example: unauthorized client, throttling (too many request within time frame) or server instance shutdown.
However there's a lot of reasons which can lead to have Websockets closed and Websockets can drop without notification (sending close message). We don't implement any explicit heartbeat solution, I guess the NET component support standard ping/pong via standard opcodes.
The Ping/Pong solution
What is the Ping/Pong solution ?
The interface software will send a WebSocket Ping request to Mews every 5 minutes to monitor the connection. If the Ping request fails, the interface will be restarted automatically, and the synchronization process will be triggered when successfully connected again.
Is the ping/pong solution implemented through our API ?
The ping/pong solution is not implemented through our API. It is a solution that should be handled by the partner.
Where can I find more information about the ping/pong solution ?
Here is the section that explains Ping and Pong with Websockets