Integrations
Hunzi works inside your hotel system, not beside it. This page says what is genuinely connected today - and the list is growing.
Last updated: 2026-08-20
There is no logo wall on this page.
That is deliberate. Forty grey logos on a vendor's page usually mean that forty systems can export a CSV file. An integration that changes anything in daily work looks different: it reads availability at the moment a guest asks, and it writes the reservation back to the place your front desk already looks.
So the list here is short: it names what runs today.
And it is growing. For the PMS that is ibelsa.rooms today. More systems are being worked on, and they appear here once a property can genuinely use them, not before. If yours is missing, tell us which one: the order follows what hotels ask for.
What runs today
ibelsa.rooms. The property management system is the system of record, and it stays that way. Hunzi reads availability, rates and room stock from it, creates reservations and writes corrections back. There is no second copy of the data that could drift apart. The details, limits included, are on the ibelsa page.
ibelsaPay. Payment links are created against the reservation itself. The guest gets a hosted payment page, the money runs through your existing payment service provider, and the payment is attached to the right booking without anyone attaching it.
Email. Your property's own mailbox, inbound and outbound. Enquiries are read and answered, delivery problems are detected, and addresses that are permanently unreachable are suppressed rather than written to again.
Slack. Events from Hunzi land in the channel your team already sits in. The content is deliberately sparse: no guest messages, no names, no room numbers. Anyone who needs the detail clicks through to the dashboard.
Your own systems. For anything without a ready-made building block there is an outbound webhook to an address of your choosing, whether that is Zapier, Make, n8n or something you built yourself. Every request is signed, so your system can verify that it genuinely came from us and that nothing was altered on the way.
Where your credentials sit
You enter your PMS credentials once, in the admin area. They are stored encrypted and never displayed again, not even to you: the interface only says that a value is set, not what it is. Anyone who suspects a wrong value replaces it rather than reading it back.
If no master key for the encryption is configured, the system refuses to accept the credentials at all. That is the more inconvenient of the two possible reactions and the only one that leaves nothing sitting in plain text.
Limits
An integration is not a switch. Every system has its own vocabulary for room categories, rates and cancellation rules, and that vocabulary has to be reconciled once. That is work a person does, and we do it with you. Anyone telling you it takes an hour has not done it.
What the PMS cannot do, Hunzi cannot do either. We do not rebuild a function your system does not offer. If ibelsa has no tentative reservation status, Hunzi does not get one either, and we solve that visibly differently instead of staying quiet about it. The ibelsa page has the detail.
A second PMS is work, not a checkbox. The interface in the code is vendor-neutral so that another system fits behind it technically. That is the precondition, not the integration.
The difference
Most integration lists answer the question of how many systems a vendor can talk to.
The question that counts in daily operation is a different one: what happens to the late arrival a guest announces by phone at 11pm? With an export-style integration it becomes a note somebody retypes tomorrow. Here it becomes a reservation correction in the PMS and an entry in housekeeping's room plan, without anyone retyping anything.
That does not take forty connections. It takes one that writes.