Events guidelines

In situations where we need to sync information between two different platforms we recommend to use Ulyses Cloud’s events instead trying to manage everything manually. This will save you tons of work ;)

By definition Ulyses Cloud’s events are the collection of changes that applies over some specific information such as companies, customers, rooms or roomstays. These can be either triggered by end-users manually or by Ulyses Cloud automatically.

The best way to explain the syncing process is by means of an example. Let’s figure out that we want to sync the information of UC’s customers with a Guest CRM (from now on known as “Provider”).

The steps that we need to follow are showed below and detailed further afterwards

Open

Step 0 – Initial data import (UC to Provider)

If we want to load all information (customers, rooms, roomstays, companies) from UC to the Provider we will need to perform a Full Refresh of the information. To do this we will need to login to our account at Ulyses cloud, go to Ulyses Connections and make sure our user is subscribed to the Customer’s events, click in the Full Refresh button and enter the period throughout you want to load data.

 The Full Refresh will fill in the events queue with all the customer ids that have been created in Ulyses Cloud. From now on, the Provider will need to request the list of pending events.

Step 1 – Get list of entities with changes (Provider to UC)

Whether the provider needs to get an initial data import or not, whenever a user or Ulyses Cloud performs a change over an event entity (ie Customer, Company, Room or Roomstay) and this remains active in the Events on Ulyses Connections, the entity’s ID will be added to a queue that can be requested by the Provider through the following endpoint.

Whenever the Provider requests this information he will receive a list of changes affecting as many entities as he will be subscribed. Hence, if the Provider is subscribed , for example, to Roomstays and Room events they will get a response similar to the following, where the publicAPIEventEntity corresponds to the entity.

Read carefully

The list of events generated will be marked as PENDING. However, after 24h of being set as PENDING they will me marked automatically as EXPIRED. While being PENDING, the API user will receive mails every hour.

 Step 2 – Get the details of the Event Entity (Provider to UC)

Once the Provider knows the list of entities which suffered changes, it will need to know what changed exactly. To do that the Provider will request the detail of the entity ID through the correspondent endpoint and will compare the object against its existing information. 

• Click here to get the details of a roomstay given its ID

• Click here to get the details of a customer given its ID

• Click here to get the details of a company given its ID

• Click here to get the details of a room given its ID

Following with the example, if we know there was a change on the Customer’s ID = 121, you will get the details of this customer’s id by requesting the following method.

Step 3 – Confirm that the details were received (Provider to UC)

When data was received by the Provider, it will confirm that received the information correctly or not through the following endpoint.