Crear reserva pública
Permite que una persona sin sesión cree desde la web pública de Marea Gran Via una reserva confirmada con canal `web` o una entrada en lista de espera cuando la pantalla no encuentra huecos. La ubicación y el servicio deben estar publicados, el servicio debe ser público y automático, y cada envío usa `idempotency_key` para evitar duplicados.
En este artículo
Este flujo cubre el momento en que el cliente ya ha llegado a la web pública, ha elegido fecha, servicio, personas y, para una reserva confirmada, un hueco disponible devuelto por disponibilidad.
Al confirmar, Antylogic vuelve a validar que la ubicación sea reservable, que la ocurrencia siga abierta y que el slot siga disponible. Si el mismo intento se repite con la misma huella, se devuelve la reserva existente en lugar de crear otra.
Antes de empezar
- Marea Gran Via debe existir para el `orgId` y `locationId` de la URL, no estar borrada, tener la suscripción no bloqueada, `public_booking_enabled=true` y el permiso de plan `reservation-automatic:use`.
- Debe existir una ocurrencia futura de tipo `service`, `visibility=public`, `booking_mode=automatic` y `acceptance_state=open`; los servicios `internal` no son reservables en la web pública actual.
- Para `status: booked`, la pantalla pública debe haber seleccionado un slot devuelto por `POST /api/public/{orgId}/{locationId}/booking/availability`.
- El cliente debe introducir `customer_name` y `customer_phone`; email, comentario, preferencias de mesa, duración y `locale` son opcionales.
- La pantalla debe enviar un `idempotency_key` y renovarlo solo cuando cambie la huella del payload.
Instrucciones
- 1.
Abrir la web pública
El cliente entra en `/:orgId/:locationId/booking` o en el alias soportado `/:orgId/:locationId/reservar`. La página carga la ubicación Marea Gran Via y solo continúa si la reserva pública está habilitada para esa ubicación.
- 2.
Elegir fecha y servicio
El cliente selecciona una fecha futura y un servicio público automático. Los servicios manuales pueden mostrarse como información, pero la pantalla bloquea la continuación y pide contacto directo; los servicios `internal` quedan fuera del calendario público.
- 3.
Consultar disponibilidad
El cliente indica el número de personas y, si están habilitadas, preferencias públicas de zona o tipo de mesa. La pantalla llama a `POST /api/public/{orgId}/{locationId}/booking/availability` y, si hay huecos, conserva el `starts_at` elegido.
- 4.
Completar datos de contacto
En el paso `Tus datos`, el cliente introduce nombre y teléfono. Puede añadir email y comentario para el local. Con esos datos, la pantalla calcula la huella estable del payload y mantiene o renueva el `idempotency_key`.
- 5.
Confirmar la reserva
La pantalla envía `POST /api/public/{orgId}/{locationId}/booking/reservations` con `status: booked`, la ocurrencia, el horario seleccionado, personas, contacto, preferencias permitidas, nota e `idempotency_key`. El backend crea o reutiliza el cliente por teléfono dentro de la ubicación y registra la reserva con canal `web`.
- 6.
Mostrar el resultado
Si el slot sigue disponible, la pantalla muestra `Reserva confirmada`. Internamente se invalida la caché de optimización de la ocurrencia, se intenta optimización posterior y se notifica a los responsables con `reservation:manage`.
- 7.
Usar lista de espera si no hay huecos
Cuando disponibilidad termina correctamente con cero slots, la pantalla puede enviar `status: waitlist`. En ese caso no exige `starts_at`; la reserva queda en espera asociada a la ocurrencia y genera la notificación interna de lista de espera pública.
Validaciones y límites
- La ruta de creación solo acepta `POST`; JSON inválido devuelve `payload invalido`.
- `occurrence_id`, `customer_name`, `customer_phone`, `idempotency_key` y `party_size > 0` son obligatorios.
- `status` vacío se interpreta como `booked`; solo se aceptan `booked` y `waitlist`.
- Para `booked`, `starts_at` es obligatorio y debe coincidir con un slot recalculado justo antes de crear la reserva.
- Si el mismo `idempotency_key` llega con la misma huella, se devuelve la reserva existente; si llega con otra huella, se responde conflicto en `idempotency_key`.
- Si `public_booking_table_preferences_enabled=false`, el backend ignora `preferred_table_ids`, `table_type_id` y `table_type_mode`.
- La UI pública no envía `table_ids`, por lo que no debe prometerse asignación automática de mesas como resultado garantizado.
- No se observa validación de formato de teléfono o email en esta acción, más allá de exigir que el teléfono no esté vacío.
Resultado esperado
La solicitud queda registrada en Marea Gran Via como reserva confirmada o entrada de lista de espera, siempre con canal `web`, trazabilidad por `idempotency_key` y notificación interna para el equipo responsable.