Known caveats and notes

A common question we receive from booking systems willing to integrate with Wherewolf is:

Why Wherewolf requires a booking details API endpoint if all the booking information could be sent over within the webhook call?

Wherewolf hesitance on relying only on webhook calls comes from previous experiences that resulted in extra work required, mainly:

• Booking systems will often queue the update calls (so these can be re-issued if/when failed), but calls from these queues can get out of order and/or arrive at the same time (specially for booking systems where the order is confirmed on a 1st step and details are optionally added in subsequent steps). Including an “updatedAt” in the payload and then ignoring calls with older timestamps is a common solution for this scenario, but this only works when you can ensure calls are arriving one after another. When calls arrive at the same time to Wherewolf, they could get assigned to different workers and processed at the same time. Therefore, each individual process can’t rely on the timestamp alone anymore causing the need for locks, and a buffer/queue to ensure only one update is executed at any given time. From previous experiences, this added complexity is in general not worth it.

• Back-fills, when integrating new clients Wherewolf needs to retrieve any already made booking for the near future (commonly one year). Booking systems could expose an endpoint to allow Wherewolf to trigger webhooks for all bookings with future dates, but this does not provide any way to control the flood of calls that a big client could cause.

• There is no way for Wherewolf to know if there were update calls that never arrived, and, at the end of the day Wherewolf is responsible on what is being displayed in the iPad at location, and is this the reason why (depending on the integration type) Wherewolf will re-fetch the booking details for the current day (or beyond) on well spaced intervals to ensure consistency against webhook calls.