ibelsa Integration

Stand: 2026-08-17

Hunzi liest und schreibt über die offene API von ibelsa.rooms. Dein PMS bleibt das führende System: Hunzi legt Reservierungen dort an, fragt dort Verfügbarkeiten ab und schreibt Korrekturen dorthin zurück. Es gibt keine zweite Datenhaltung, die auseinanderlaufen könnte.

Diese Seite beschreibt, was die Anbindung heute kann, wie sie eingerichtet wird, und, ausführlicher als üblich, wo ihre Grenzen liegen. Die Grenzen stehen hier, weil sie in der Praxis den Unterschied machen und weil du sie vor der Entscheidung kennen solltest, nicht danach.

Was Hunzi aus ibelsa liest

• Verfügbarkeiten je Zeitraum, Ratenplan und Personenzahl, mit Preisen pro Nacht und Zimmerkategorie
• Zimmerbestand des Hauses
• Belegung des laufenden Tages
• Reservierungsdetails zu einer bestehenden Buchung

Was Hunzi nach ibelsa schreibt

• Reservierung anlegen: aus einem Gespräch am Telefon, im Chat oder über WhatsApp
• Zimmer zu einer bestehenden Reservierung hinzufügen
• Reservierung stornieren
• Kontaktdaten korrigieren: wenn die Spracherkennung einen Namen falsch verstanden hat und der Gast ihn im Formular richtigstellt
• Zahlungslink über ibelsaPay erzeugen

Wie die Verbindung entsteht

Die Anbindung braucht keinen Entwickler auf deiner Seite und keinen Eingriff in dein System.

1. Du erzeugst in ibelsa einen API-Key für dein Haus und gibst Hunzi in der Liste der zugelassenen API-Nutzer frei. Welche Daten freigegeben werden, entscheidest du. 2. Der Key wird im Hunzi-Adminbereich hinterlegt. 3. Fertig. Hunzi authentifiziert sich ab dann pro Anfrage mit diesem Key.

Sicherheit

Der Key wird pro Anfrage gesetzt, nie auf einer geteilten Verbindung. Das ist der Grund, warum bei mehreren Häusern auf derselben Installation kein Key an die Anfrage eines anderen Hauses geraten kann.

Im Klartext liegt er nirgends. Hinterlegte Keys werden verschlüsselt gespeichert; alternativ speichert Hunzi nur den Namen einer Umgebungsvariable und löst den Wert erst zum Zeitpunkt des Aufrufs auf. Der Adminbereich gibt einen hinterlegten Key nie wieder aus. Er zeigt nur, dass einer gesetzt ist.

Fehlermeldungen aus ibelsa werden nicht durchgereicht. Die Schnittstelle antwortet im Fehlerfall teilweise mit vollständigen Stapelspuren und Server-Pfaden. Hunzi ersetzt diese durch eine eigene, inhaltsleere Meldung, so dass weder ein Gast noch ein Protokoll je den Originaltext sieht.

Fehlt ein hinterlegter Key, greift Hunzi auf keinen anderen zurück. Die Anbindung schlägt fehl, statt sich still an einer allgemeinen Zugangsdatei zu bedienen.

Die gesamte Verarbeitung findet in der EU statt. Ein AV-Vertrag nach Art. 28 DSGVO liegt vor.

Grenzen

Fünf Punkte, die die Anbindung heute nicht kann. Vier davon liegen an ibelsa, nicht an Hunzi. Wir nennen sie trotzdem, weil sie für dein Tagesgeschäft denselben Unterschied machen, egal woran sie liegen.

1. ibelsa kennt keine vorläufige Reservierung

Es gibt in ibelsa keinen Status zwischen „frei" und „gebucht". Solange ein Gast im Gespräch noch überlegt, kann das Zimmer dort nicht reserviert werden, ohne es zu buchen.

Hunzi hält das Zimmer deshalb 15 Minuten auf der eigenen Seite und legt die Reservierung erst an, wenn der Gast zusagt. Innerhalb dieser 15 Minuten ist das Zimmer für andere Hunzi-Gespräche blockiert, für eine Buchung, die in derselben Minute direkt in ibelsa entsteht, jedoch nicht.

2. Für künftige Tage gibt es keine Zimmerzuteilung

In ibelsa wird das konkrete Zimmer erst beim Check-in festgelegt. Für einen Tag in der Zukunft steht deshalb nur fest, wie viele Zimmer belegt sind, nicht welche.

Das ist keine Einschränkung der Schnittstelle, sondern der Zustand der Daten: die Zimmer sind zu diesem Zeitpunkt tatsächlich noch nicht entschieden. Hunzi zeigt für künftige Tage deshalb Summen statt eines Zimmerplans. Für den laufenden Tag, an dem die Zuteilung feststeht, zeigt es beides.

3. Namenskorrekturen laufen über die Kontaktdaten

Der von ibelsa dokumentierte Endpunkt zum Ändern der Gästedaten einer Reservierung antwortet nicht. Hunzi schreibt Korrekturen deshalb über die Kontaktdaten des Gastes zurück. Das Ergebnis ist dasselbe: der Name steht korrekt in der Reservierung. Der Weg ist ein anderer.

4. Schreibvorgänge werden nicht automatisch wiederholt

Wenn die Verbindung während des Anlegens einer Reservierung abbricht, versucht Hunzi es nicht erneut. Ein Abbruch nach der Verarbeitung, aber vor der Antwort, würde sonst eine zweite Reservierung erzeugen.

Lesende Abfragen werden wiederholt, weil sie nichts verändern. Der Unterschied ist bewusst: eine doppelte Buchung ist teurer als eine wiederholte Frage.

5. Der Zahlungslink setzt eine bestehende Reservierung voraus

ibelsaPay bindet einen Zahlungslink an ein Folio, und ein Folio entsteht erst mit der Reservierung. Die Reihenfolge ist deshalb: Reservierung anlegen, Folio offen lassen, Zahlungslink erzeugen. Ein Link vor der Buchung ist über diesen Weg nicht möglich.

Andere Systeme

Heute ist ibelsa das einzige produktiv angebundene PMS. Wir nennen keine weiteren, solange sie nicht laufen: eine Integrationsliste, die Absichten als Anbindungen führt, merkst du erst, wenn du sie brauchst.

Wenn du ein anderes System einsetzt, sprich uns an. Wir sagen dir ehrlich, ob und wann es sinnvoll ist.