How can entities be connected?
The basis of webhooks is the exchange of data about an entity.
This is relatively simple for an entity that is created. The attributes are passed along and the target application does "something" with them (usually creating a similar entity).
But what should happen with an entity that is updated?
This is more complex, since the target application needs to know which entity is being referred to.
For example: a reservation is made for January 10 from 12:00 to 14:00.
As a result of the webhook integration, a calendar item is created in a calendar (for example Google Calendar or Microsoft Outlook).
Now the user changes the reservation from January 10 to January 11.
The expected result: the calendar is also updated.
The actual result, however, will be that a calendar item is visible on both January 10 and January 11.
There are several methods to improve this "undesirable" result.
Outgoing: an updated reservation to Google Calendar
The integration platform Zapier includes an app to connect with a Google Calendar.
To handle both new and updated items, we apply logic already in the first step.
We can create a calendar item based on the reservation. We can assign a description (subject) to the item itself.
This could be the product description, but also a combination that includes the reservation number.
We choose a text field with "IRES{{reservation number}}: {{product description}}" which then becomes "IRES3691: Main hall".
When updating the reservation, we choose a "Search" or "Find Event".
This search requires a "Search Term": here we enter "IRES{{reservation number}}".
The corresponding calendar item is then updated with the new date and time.
Note: the drawback of this method is that if the user changes the description in Google Calendar, the search action will not return a result.
Incoming: creating and updating a reservation in Office 365
We use the integration platform Microsoft Flow and connect an Outlook calendar with i-Reserve.
A user creates a calendar item. The integration specifies which product in i-Reserve must be used and ensures that a reservation is created.
At that point, the calendar does not know what the reservation number is, but it does not need to.
An extra attribute is created in i-Reserve, namely an "External ID". This can be specified in the integration.
A value must be provided that is unique and contains the same value for both a new and an updated item.
This could, for example, be the iCalUID.
When an updated reservation is then sent, the correct reservation is automatically retrieved based on this external ID.