The notification service allows you to build or set up apps which subscribe to certain events on apaleo (webhooks). When an event is triggered, we send an HTTP POST payload to the configured URL.
Webhooks can be used to send reservation confirmations or check-out emails with the invoice attached, issuing mobile keys on check-in and much more.
Webhooks can be configured per property and topic. All you need to do is subscribe to a topic on https://notifications.apaleo.com.
The URL you provide in the request needs to be secure and start with https, and it needs to be reachable from apaleo.com. If you're not sure, check with your security or ops team, if any firewalls prevent incoming traffic on (usually) port 443, and ask to whitelist us.
To unsubscribe, delete the subscription.
When subscribing, you can choose events from which topic you want to receive. A topic is grouping events of several types. The available events are:
The list of types within one topic can grow in the future, make sure your implementation is prepared for unexpected event types appearing in the payloads.
Events we send to your webhooks all have the same structure:
Typically, you might want to use this information to query more data. For example, get the reservation entity by its ID. The 'data' element is optional and can in the future contain payloads with different schemas. For now, it's always the entityId.
After you subscribe, apaleo sends a health-check event. If that fails, the subscription will fail and return an error.
apaleo will continue pinging you every two minutes for each subscription - that way you know that everything still works, even if no new events happened. If the same URL endpoint is used for two different subscriptions, it will receive two health checks.
You can also trigger the ping yourself, using the healthcheck API. This is a great way to test if your URL can generally be reached and handle the request. The message sent by the ping is a sample reservation created event.
Guarantees and error handling
Under normal circumstances, you will receive the notification latest 60 seconds after the actual event happened in apaleo.
Events are not sent in any specific order, and it can happen that you receive, for example, a 'reservation canceled' before a 'reservation created' event. You can use the timestamp to order events.
Each event is delivered at least once. You can deduplicate them using the ID field.
The notification service expects your endpoint to respond with a 2xx success code, also for event types you are not supporting. When something goes wrong, return 4xx or 5xx error codes, just like you always do. If a delivery attempt fails, we will try resending the event every minute.
Even if one of the events is not acknowledged by you with a 2xx, apaleo continues sending the other events.
Posted byAndrea Stubbe