Reservar para agentes de IA

Solicite una estancia directamente, sin plataforma de reservas: los asistentes de IA pueden consultar disponibilidad y precios y enviar una solicitud con el permiso del huésped.

Solicitud → confirmación del anfitrión → pago

La solicitud expresa el compromiso de reservar según las condiciones acordadas, pero ni el presupuesto ni la solicitud recibida son una reserva confirmada. El anfitrión revisa y confirma la estancia. Después se paga por transferencia según las condiciones acordadas. Una llamada a una herramienta no cobra ni confirma una reserva.

Se mantienen el permiso y la protección

El huésped debe autorizar la solicitud y la transmisión de sus datos. Las llamadas POST usan la misma sesión web, validación CSRF, pruebas nuevas de un solo uso (hashcash/CAPTCHA), honeypot y límites que el formulario. Obtenga sesión y pruebas mediante el diálogo habitual, nunca pruebas ficticias. No repita automáticamente un envío de resultado incierto. No incluya secretos ni datos de huéspedes en prompts, terminal o registros.

Interfaces legibles por máquinas

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
Disponibilidad: GET /api/accommodation/availability
Presupuesto: POST /api/accommodation/price-quote
Solicitud de reserva (pendiente): POST /api/accommodation/booking
A2A Agent Card (Preview)
OAuth Authorization Server (RFC 8414) · Protected Resource (RFC 9728)
llms.txt · Sitemap · robots.txt

Exactamente dos calendarios iCal públicos

Los feeds solo muestran periodos ocupados, nunca nombres ni números de reserva. DTEND de iCal es exclusivo; los intervalos REST incluyen el último día. Un periodo libre no garantiza una reserva.

Ejemplo MCP de solo lectura

Envíe POST application/json a /api/accommodation/mcp. Primero initialize, después tools/list y tools/call. Compruebe isError y _meta.httpStatus. La disponibilidad es de lectura; precios y solicitudes requieren además las pruebas habituales del formulario.

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

Estándares y limitaciones reales

OAuth 2.0 (client credentials) está disponible para claves de agente emitidas: metadatos en /.well-known/oauth-authorization-server, token mediante POST /api/oauth/token. La delegación de huéspedes, un agente que actúa en nombre de un huésped con su consentimiento, no está disponible. Las solicitudes de reserva siguen usando el diálogo web habitual con la autorización del huésped.

La Agent Card A2A sirve solo para descubrimiento (preview). No hay un servidor de tareas A2A. Las funciones disponibles se describen en REST/OpenAPI y MCP.

UCP (Universal Commerce Protocol 2026-08-25): el perfil del negocio está en /.well-known/ucp. Un checkout de compras UCP no puede transmitir fechas de estancia, por lo que redirige al formulario de solicitud mediante continue_url. Los agentes solicitan estancias con el borrador de alojamiento (dev.ucp.lodging.booking) en /api/ucp/booking-sessions: property.id fewo-tremmel, apartamento, tarifa standard, fechas y número de huéspedes. Como el borrador aún no está publicado, no figura en el perfil y puede cambiar. La finalización envía una solicitud de reserva no vinculante (estado complete_in_progress) que confirma el anfitrión; nunca se presenta como reserva confirmada. La admisión como socio de Google se gestiona externamente.

Stripe no es necesario para solicitud → confirmación → transferencia. Un futuro flujo de pago Google UCP puede requerir un proveedor que tokenice pagos, no necesariamente Stripe. No se ha realizado ningún registro externo.