Booking for AI agents

Request a stay directly without a booking platform: AI assistants can check availability, request quotes and submit a booking request with the guest’s permission.

Request → host confirmation → payment

A booking request expresses a binding wish to book under the agreed terms, but neither a quote nor a received request is a confirmed reservation. The host reviews and confirms the stay. Payment then follows the agreed terms by bank transfer. A tool call alone neither charges a payment nor confirms a reservation.

Permission and protection still apply

The guest must authorize the request and transmission of their details. POST calls use the same website session, CSRF validation, fresh single-use proofs (hashcash/CAPTCHA), honeypot and rate limits as the form. Obtain the session and proofs through the normal booking dialog, never dummy proofs. Do not automatically retry an uncertain submission. Keep secrets and guest details out of prompts, terminal output and logs.

Machine-readable interfaces

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
Availability: GET /api/accommodation/availability
Price quote: POST /api/accommodation/price-quote
Booking request (pending): POST /api/accommodation/booking
A2A Agent Card (Preview)
OAuth Authorization Server (RFC 8414) · Protected Resource (RFC 9728)
llms.txt · Sitemap · robots.txt

Exactly two public iCal calendars

Feeds expose busy periods only, never names or booking numbers. iCal DTEND is exclusive; REST availability ranges include their final day. An available period is not a reservation guarantee.

Read-only MCP example

POST application/json to /api/accommodation/mcp. Start with initialize, then tools/list and tools/call. Inspect isError and _meta.httpStatus in tool results. Availability is read-only; quotes and requests also require the normal form proofs.

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

Standards and honest limitations

OAuth 2.0 (client credentials) is available for issued agent keys: metadata at /.well-known/oauth-authorization-server, token via POST /api/oauth/token. Guest delegation, an agent acting for a guest with their consent, is not available. Booking requests still use the normal website dialog with the guest’s permission.

The A2A Agent Card is discovery-only (preview). No A2A task server is exposed here. Callable functions are described by REST/OpenAPI and MCP.

UCP (Universal Commerce Protocol 2026-08-25): the business profile is at /.well-known/ucp. A UCP shopping checkout cannot carry stay dates, so it hands off to the request form via continue_url. Agents request stays through the lodging draft (dev.ucp.lodging.booking) at /api/ucp/booking-sessions: property.id fewo-tremmel, apartment, rate standard, stay dates and number of guests. Because the draft is not yet released, it is not listed in the profile and may change. Completion submits a non-binding booking request (status complete_in_progress) that the host confirms; it is never reported as a confirmed reservation. Google partner onboarding happens externally.

Stripe is not required for request → confirmation → bank transfer. A future Google UCP payment flow may require a suitable tokenizing payment service provider, not necessarily Stripe. No external registration has been performed.