Die Sixto API: dieselben Aktionen und Berechtigungen wie für dein Team
Die Sixto API stellt dieselben Aktionen wie die App bereit, etwa Aufgaben, Datensätze, Berichte und Nachrichten. Schlüssel erhalten nur die von dir vergebenen Berechtigungsbereiche. Jeder Aufruf wird im Aktivitätsprotokoll des Schlüssels erfasst. Ein Schlüssel kann seine Identität und erlaubten Aktionen abfragen. Sensible Aktionen warten auf die Bestätigung einer Person.
Verfügbar. Eine versionierte REST API mit begrenzten Schlüsseln deckt Reservierungen, Gäste, Aufgaben, Finanzen, Check-in, Schlösser, Kanäle und mehr ab.
Deine Werkzeuge, begrenzter Zugriff
API-Schlüssel erhalten nur die von dir gewählten Berechtigungen
Was die Integration leistet
Sieh, welche Daten übertragen werden und welche bleiben
Die Pfeile zeigen die Datenrichtung aus Sicht von Sixto.
Breite Abdeckung
Aufgaben, Reservierungen, Gäste, Bewertungen, Nachrichten, Check-in, Compliance, Schlösser, Kanäle, elektronische Rechnungen, Bank und Hauptbuch, Marktvergleiche, Suche und Einstellungen.
Begrenzte Schlüssel aus einem Berechtigungskatalog
Schlüssel nutzen denselben Berechtigungskatalog wie Personen. Zum Ändern von Berechtigungen erstellt eine Person mit der Rolle Inhaber einen Ersatzschlüssel und widerruft den alten. Der Widerruf wirkt beim nächsten Aufruf.
Selbstbeschreibend
Frage die API nach deiner Identität und deinen erlaubten Aktionen (whoami und capabilities), einschließlich der nötigen Berechtigungen jeder Route.
Sichere Wiederholungen und Aktivitätsprotokoll
Jeder Schreibvorgang dokumentiert seine Wiederholungskennung, etwa external_id oder einen Idempotency-Key-Header. Wird dieselbe Kennung mit anderem Inhalt verwendet, antwortet er mit 409. Jede Anfrage hat eine ID und erscheint im Aktivitätsprotokoll.
Faire Limits
Jeder Schlüssel hat sein eigenes Kontingent, standardmäßig 600 Anfragen pro Minute. So verlangsamt ein stark genutzter Schlüssel keinen anderen. GET /api/v1/capabilities meldet den aktuellen Wert.
Lieber eine KI-App? Nutze MCP
Neben der REST API hat Sixto einen MCP-Server für KI-Apps mit OAuth-Anmeldung, der deaktiviert bleibt, bis eine Person mit der Rolle Eigentümer oder Manager ihn aktiviert. Dazu kommt ein öffentlicher, schreibgeschützter Docs MCP.
- Serveradresse
https://holasixto.com/mcp- Docs MCP
https://holasixto.com/mcp/docsÖffentlich und schreibgeschützt. Durchsucht die Sixto-Dokumentation und hat niemals Zugriff auf die Daten deiner Organisation.
So funktioniert es
- 01
Eine Person mit der Rolle Inhaber erstellt unter Einstellungen einen Schlüssel und wählt die nötigen Berechtigungen. Der Schlüssel wird einmal angezeigt.
- 02
Sende ihn als Bearer-Token. Rufe whoami und capabilities auf, um die Möglichkeiten des Schlüssels zu sehen.
- 03
Lies oder schreibe über die Endpunkte. Schreibvorgänge durchlaufen dieselben Prüfungen wie die App.
- 04
Verfolge Aufrufe in der API-Aktivitätsansicht und widerrufe einen Schlüssel jederzeit.
Welche Daten synchronisiert werden
Häufige Fragen
Gibt es eine Entwickleranleitung?
Ja. Die OpenAPI-3.1-Referenz steht unter /api/v1/openapi.json, die Client-Anleitung unter /api/v1/guide.json. Jede Operation zeigt x-contract-status: complete bedeutet einen geprüften Vertrag; unsupported bedeutet, dass die Route verfügbar bleibt, aber außerhalb der unterstützten Client-Schnittstelle liegt. Ein nur lesender Dokumentationsserver steht unter /mcp/docs bereit.
In wessen Namen handelt ein Schlüssel?
Ein Schlüssel handelt innerhalb seiner eigenen Berechtigungen für die Organisation. Er hat keine eigene Betriebsliste und übernimmt nicht die Betriebsgrenzen der erstellenden Person. Leitet Sixto die Anfrage einer Person mit einer Sixto-On-Behalf-Of-Delegation weiter, gelten zusätzlich deren aktuelle Betriebs- und Berechtigungsgrenzen.
Wie ändere ich die Berechtigungen eines Schlüssels?
Erstelle einen Ersatzschlüssel mit den gewünschten Berechtigungen, stelle dein Werkzeug darauf um und widerrufe danach den alten Schlüssel. Bestehende Schlüssel können nicht bearbeitet werden. Ein widerrufener Schlüssel wird beim nächsten Aufruf abgewiesen.
Was bedeuten 422 und 429?
422 bedeutet eine fehlgeschlagene Validierung: Lies das errors-Objekt nach Feld, korrigiere die Eingabe und sende erneut. 429 bedeutet, dass der Schlüssel sein Limit erreicht hat: Warte die im Retry-After-Header angegebene Anzahl Sekunden und versuche es danach mit zunehmenden Wartezeiten erneut. Bewahre die X-Request-Id auf, um den Aufruf im Aktivitätsprotokoll zu finden.
Kann ein Schlüssel eine Tür entriegeln?
Nein. Fernentriegelung ist über die API niemals verfügbar.
Ist die API versioniert?
Ja, sie liegt unter /api/v1.