Buchen für KI-Agenten

Direkt anfragen ohne Buchungsplattform: KI-Assistenten können Verfügbarkeit prüfen, Preise erfragen und mit Erlaubnis des Gasts eine Buchungsanfrage senden.

Anfrage → Gastgeberbestätigung → Zahlung

Eine Buchungsanfrage ist ein verbindlicher Buchungswunsch nach den vereinbarten Bedingungen, aber wie ein Preisangebot noch keine bestätigte Reservierung. Der Gastgeber prüft und bestätigt den Aufenthalt. Bezahlt wird anschließend gemäß den vereinbarten Zahlungsbedingungen per Überweisung. Keine Zahlung und keine verbindliche Zusage durch einen bloßen Tool-Aufruf.

Erlaubnis und Schutz bleiben erhalten

Der Gast muss die Übermittlung seiner Daten und die Anfrage erlauben. POST-Aufrufe verwenden dieselbe Website-Sitzung, CSRF-Prüfung, frische Einmal-Nachweise (Hashcash/CAPTCHA), Honeypot- und Rate-Limits wie das Formular. Sitzung und Nachweise über den normalen Buchungsdialog beziehen; keine Dummy-Nachweise. Bei unklarem Versandstatus nicht automatisch erneut senden. Geheimnisse und Gastdaten gehören nicht in Prompts, Terminalausgaben oder Logs.

Maschinenlesbare Schnittstellen

OpenAPI 3.1 (JSON)
ACP payments.json · ACP product feed
UCP profile (/.well-known/ucp) · UCP Lodging: POST /api/ucp/booking-sessions
MCP: POST /api/accommodation/mcp
Verfügbarkeit: GET /api/accommodation/availability
Preisangebot: POST /api/accommodation/price-quote
Buchungsanfrage (ausstehend): POST /api/accommodation/booking
A2A Agent Card (Preview)
OAuth Authorization Server (RFC 8414) · Protected Resource (RFC 9728)
llms.txt · Sitemap · robots.txt

Genau zwei öffentliche iCal-Kalender

Die Feeds zeigen ausschließlich Belegtzeiträume, keine Namen oder Buchungsnummern. iCal-DTEND ist exklusiv; REST-Verfügbarkeitszeiträume enthalten den letzten Tag. Ein freier Zeitraum ist keine Reservierungsgarantie.

Lesendes MCP-Beispiel

POST als application/json an /api/accommodation/mcp. Zuerst initialize, dann tools/list und tools/call. Bei Tool-Antworten isError und _meta.httpStatus prüfen. Verfügbarkeit ist lesend; Preis und Anfrage benötigen zusätzlich die normalen Formularnachweise.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "availability",
    "arguments": {}
  }
}

Standards und ehrliche Grenzen

OAuth 2.0 (Client Credentials) steht für ausgegebene Agent-Schlüssel bereit: Metadaten unter /.well-known/oauth-authorization-server, Token per POST /api/oauth/token. Eine Gastdelegation, also ein Agent, der im Namen eines Gasts mit dessen Einwilligung handelt, ist nicht verfügbar. Buchungsanfragen laufen weiterhin über den normalen, vom Gast freigegebenen Website-Dialog.

Die A2A Agent Card dient zur Discovery (Preview). Es gibt hier keinen A2A-Task-Server. Aufrufbare Funktionen stehen in REST/OpenAPI und MCP.

UCP (Universal Commerce Protocol 2026-08-25): Das Geschäftsprofil steht unter /.well-known/ucp. Ein UCP-Shopping-Checkout kann keine Reisedaten übertragen und leitet deshalb per continue_url zur Anfrage weiter. Aufenthalte fragen Agenten über den Lodging-Entwurf (dev.ucp.lodging.booking) unter /api/ucp/booking-sessions an: property.id fewo-tremmel, Wohnung, Rate standard, Reisedaten und Personenzahl. Weil der Entwurf noch nicht veröffentlicht ist, steht er nicht im Profil und kann sich ändern. Der Abschluss sendet eine unverbindliche Buchungsanfrage (Status complete_in_progress), die der Gastgeber bestätigt; sie wird nie als bestätigte Reservierung ausgegeben. Die Google-Partneraufnahme erfolgt extern.

Stripe ist für Anfrage → Bestätigung → Überweisung nicht erforderlich. Ein späterer Google-UCP-Zahlungsfluss kann einen geeigneten tokenisierenden Zahlungsdienstleister verlangen, nicht zwingend Stripe. Es wurde keine externe Registrierung durchgeführt.