ibelsa integration

Last updated: 2026-08-17

Hunzi reads and writes through the open ibelsa.rooms API. Your PMS stays the system of record: Hunzi creates reservations there, checks availability there, and writes corrections back there. There is no second copy of the data that could drift.

This page describes what the integration does today, how it is set up, and, in more detail than usual, where its limits are. The limits are here because they are what matters in daily operation, and because you should know them before deciding rather than after.

What Hunzi reads from ibelsa

• Availability by date range, rate plan and occupancy, with per-night prices by room category
• Room inventory
• Today's occupancy
• Reservation details for an existing booking

What Hunzi writes to ibelsa

• Create a reservation: from a conversation on the phone, in chat or over WhatsApp
• Add a room to an existing reservation
• Cancel a reservation
• Correct contact details: when speech recognition misheard a name and the guest fixes it on the form
• Generate a payment link via ibelsaPay

How the connection is made

Setup needs no developer on your side and no change to your system.

1. You create an API key for your property in ibelsa and authorise Hunzi in the list of permitted API users. You decide which data is shared. 2. The key is stored in the Hunzi admin area. 3. That is all. Hunzi authenticates with that key on every request.

Security

The key is attached per request, never to a shared connection. That is what makes it impossible for one property's key to end up on another property's request when several run on the same installation.

It is never stored in plain text. A stored key is encrypted; alternatively Hunzi keeps only the name of an environment variable and resolves the value at call time. The admin area never returns a stored key. It shows only that one is set.

Errors from ibelsa are not passed through. The interface sometimes answers failures with full stack traces and server paths. Hunzi replaces these with its own contentless message, so neither a guest nor a log ever sees the original.

If a configured key is missing, Hunzi falls back to no other key. The integration fails rather than quietly borrowing shared credentials.

All processing takes place in the EU. A data processing agreement under Article 28 GDPR is in place.

Limits

Five things the integration does not do today. Four of them are properties of ibelsa rather than of Hunzi. We list them anyway, because they make the same difference to your day either way.

1. ibelsa has no tentative reservation

There is no state between "free" and "booked". While a guest is still deciding during a conversation, the room cannot be held there without booking it.

Hunzi therefore holds the room for 15 minutes on its own side and creates the reservation only once the guest agrees. During those 15 minutes the room is blocked for other Hunzi conversations, but not against a booking made directly in ibelsa in the same minute.

2. There is no room assignment for future dates

In ibelsa the specific room is decided at check-in. For a future date, only how many rooms are occupied is known, not which ones.

This is not a limit of the interface but the state of the data: at that point the rooms genuinely are undecided. Hunzi therefore shows totals rather than a room plan for future dates. For today, where the assignment exists, it shows both.

3. Name corrections go through contact data

The endpoint ibelsa documents for changing a reservation's guest data does not respond. Hunzi writes corrections back through the guest's contact record instead. The result is the same: the correct name on the reservation. The route is different.

4. Write operations are not retried automatically

If the connection drops while a reservation is being created, Hunzi does not try again. A drop after processing but before the response would otherwise create a second reservation.

Read requests are retried, because they change nothing. The difference is deliberate: a duplicate booking costs more than a repeated question.

5. A payment link requires an existing reservation

ibelsaPay binds a payment link to a folio, and a folio only exists once the reservation does. The order is therefore: create the reservation, leave the folio open, generate the link. A link before the booking is not possible this way.

Other systems

Today ibelsa is the only PMS connected in production. We do not name others until they run: an integration list that carries intentions as connections is something you only discover when you need it.

If you use a different system, talk to us. We will tell you honestly whether and when it makes sense.