Changelog de la API

price e is_included dejan de ser campos del cuerpo: el precio y la inclusión salen de la tarifa de la categoría del huésped en ese restaurante, igual que en el PATCH desde el 2026-09-19. Antes, si el restaurante no tenía tarifa para esa categoría, se guardaba lo que mandara el integrador. Mandarlos no da error: se ignoran. Sin tarifa, la reserva queda con price: null e is_included: null, y el hotel la corrige asignándole la categoría.

Qué revisar: Si mandabas price o is_included, deja de hacerlo y lee el precio de la respuesta del POST. Si no los mandabas, no tienes que hacer nada.

El mínimo de minutos antes del turno (app_advance_booking_min_minutes) se cuenta en la zona horaria del hotel. Se contaba en la del servidor, así que en un hotel con otra zona (por ejemplo, Ciudad de México) se aceptaban o se rechazaban reservas con una hora de diferencia. Los hoteles en la zona de Cancún no cambian.

La ventana máxima de anticipación es la más corta entre max_advance_booking_days y app_max_advance_booking_days, la misma que ya aplicaba el POST. Antes la disponibilidad tomaba la de la app aunque la general fuera menor, ofrecía días que el POST después rechazaba con 409 APP_ADVANCE_VIOLATION, y ahora esa consulta responde ese mismo error.

Si la key está acotada a ciertos restaurantes, el listado ya no incluye reservas de otros restaurantes del hotel, y leer, editar o cancelar una de ellas responde 404 NOT_FOUND. Antes el alcance solo se aplicaba al crear y al consultar disponibilidad. Una key sin restricción de restaurantes no cambia.

Qué revisar: Si tu integración gestiona reservas de varios restaurantes con una key acotada, pide que la amplíen o usa una key por restaurante.

Al cambiar la date de una reserva se vuelve a evaluar el límite de visitas incluidas por estancia: si la habitación ya usó las visitas de esa categoría alrededor de la fecha nueva, responde 409 STAY_LIMIT_REACHED (antes solo se evaluaba al crear, así que el límite se podía esquivar creando la reserva en otra fecha y moviéndola). Editar sin cambiar la fecha no se ve afectado. Solo aplica en hoteles que configuraron max_per_stay.

Qué revisar: Si tu app deja mover una reserva de fecha, trata STAY_LIMIT_REACHED en el PATCH igual que en el POST: ofrece otra fecha.

En restaurantes que cobran un recargo por visita extra (en vez de bloquearla), mover una reserva incluida hacia una estancia con las visitas ya usadas también responde 409 STAY_LIMIT_REACHED: mover no recotiza el precio, y la reserva habría conservado "Incluido" donde corresponde el recargo. Una reserva que ya paga el recargo se mueve sin problema.

Qué revisar: Para esa fecha, cancela la reserva y créala de nuevo: el POST aplica el recargo.

El spec declaraba obligatorios campos que la API nunca exigió: channel, is_manual_entry, is_exceptional, allergen_ids y restriction_ids en el POST; id, allergen_ids y restriction_ids en el PATCH; y opera_reservation_id en el DELETE. La API no cambia: cambia lo que el documento dice que es obligatorio.

Qué revisar: Si validas tus cuerpos contra el OpenAPI, vuelve a bajar /api/docs/spec.

La meta de cuota (quota_exhausted, quota_limit_pax, quota_used_pax, quota_remaining_pax) estaba descrita solo en el texto de la ruta; ahora el esquema AvailabilityResponse la declara (componente AvailabilityQuotaMeta). La respuesta no cambia: meta sigue viniendo solo si el hotel te configuró un tope en ese restaurante, y con la cuota agotada no trae quota_remaining_pax.

Qué revisar: Ninguna. Si generas tipos o validas contra el OpenAPI, vuelve a bajar /api/docs/spec.

Lo que no mandes ya no se borra. Antes, un PATCH sin email, celebrations, description, children, allergen_ids o restriction_ids los dejaba vacíos (los niños en 0), aunque solo quisieras cambiar los comensales — y el GET no devuelve correo, celebraciones ni notas para poder reenviarlos. Ahora se conservan; una clave presente reemplaza, también vacía (allergen_ids: [] quita todos).

Qué revisar: Si reenviabas la reserva completa en cada PATCH para no perder datos, puedes dejar de hacerlo. Si dependías de que omitir allergen_ids los borrara, manda [] explícito.

Editar una reserva ya no altera su precio congelado. Antes, cualquier PATCH dejaba price e is_included en null, y si el cuerpo los traía, los escribía. Ahora se ignoran: el precio lo fija el servidor al crear.

Las reservas creadas con X-Mesatto-Channel: assistant ahora cuentan contra la cuota diaria del integrador (APP_QUOTA_EXCEEDED) y aparecen en el listado sin opera_reservation_id, igual que las del canal app. Antes quedaban fuera de las dos cosas.

El límite de requests por minuto (429 RATE_LIMIT_EXCEEDED) se cuenta por ORGANIZACIÓN y no por API key: todas las keys de una organización comparten la ventana de 60 s. El número es el mismo de siempre (rate_limit_per_min en GET /api/v1/me); antes cada key tenía ese cupo para sí sola.

Qué revisar: Si tu organización usa varias keys (app, kiosco, asistente), reparte el tráfico pensando en un cupo común y respeta Retry-After. Si no alcanza, pídele al hotel que suba de plan.

Código nuevo 409 IDEMPOTENCY_IN_PROGRESS: dos pedidos SIMULTÁNEOS con la misma Idempotency-Key ya no se ejecutan los dos. El primero se procesa; el segundo recibe este 409 y no escribe nada. Antes, si llegaban a la vez, podían crear dos reservas.

Qué revisar: Trátalo como reintentable: espera uno o dos segundos y repite el pedido con la misma key; recibirás la respuesta del original con Idempotent-Replayed: true.

Los mensajes de fieldErrors que antes salían con el texto por defecto en inglés (Invalid input: expected string, received undefined, Invalid UUID…) ahora salen en español, como el resto del contrato; un campo requerido ausente dice "Este campo es obligatorio". Los códigos (error) y los nombres de campo no cambian.

Qué revisar: Si tu integración compara el TEXTO de fieldErrors, deja de hacerlo: el contrato estable es error + el nombre del campo.

Mover una reserva a un día (o turno) de cierre responde 409 RESTAURANT_CLOSED, igual que el POST. Antes respondía 500 INTERNAL_ERROR.

Si el servidor no puede leer los cierres del restaurante responde 500 INTERNAL_ERROR y no escribe ni ofrece nada, en vez de tratar el día como abierto. Es transitorio: reintenta con backoff.

Cada hotel trae timezone, su zona horaria IANA (por ejemplo America/Cancun). Las fechas de las reservas son locales al hotel: úsala para calcular su "hoy" en vez del reloj de UTC, que por la tarde ya va un día adelante. Campo nuevo; no rompe a nadie.

Campo areas (id, name): las zonas que el huésped puede pedir, como "Terraza" o "Interior". Solo en restaurantes que venden por mesa; en los demás llega vacío.

Parámetro opcional area_id: con él, fits y max_available_single_table_capacity miran solo las mesas de esa zona. Una zona que el restaurante no ofrece responde 422 VALIDATION_ERROR.

Campo opcional preferred_area_id: la mesa se busca SOLO en esa zona; si no queda lugar ahí, responde RESERVATION_TABLES_FULL (409) aunque haya mesas en otra. Sin el campo, todo sigue igual. Nunca se elige una mesa concreta.

Campo table con la mesa o combinación asignada (kind, code, area, assignment: auto si la eligió el sistema, manual si una persona). Solo lectura: la API no asigna mesas. null si el restaurante no usa plano o la reserva todavía no tiene mesa.

Un restaurante puede activar la **disponibilidad por mesas**: cada reserva recibe una mesa concreta y solo se vende lo que cabe en las mesas en servicio (respetando el mínimo y el máximo de personas de cada mesa y las combinaciones que el restaurante definió). En esos restaurantes fits puede ser false aunque remaining alcance —por ejemplo, 2 personas cuando la única mesa libre es para 3 a 4—, max_available_single_table_capacity sale de las mesas reales, y el POST/PATCH responde RESERVATION_TABLES_FULL (409) cuando no hay mesa. Nada cambia hasta que el restaurante lo active.

Qué revisar: Filtra los turnos por fits con el pax real del grupo, no por remaining: es lo único que coincide con lo que el POST va a aceptar. Trata RESERVATION_TABLES_FULL como «sin disponibilidad para ese tamaño de grupo».

El corte propio de un turno para la API puede ser una hora fija del **día anterior** (antes solo del mismo día). Un turno así deja de listarse para una fecha a esa hora del día previo y el POST responde APP_CUTOFF_PASSED (409), como cualquier otro corte. En app_policy_summary.same_day_cutoff_times solo aparecen los cortes del mismo día. Nada cambia hasta que el hotel lo configure en un turno.

Qué revisar: No hay que cambiar código: el código de error y el envelope son los mismos. Si cacheas la disponibilidad de fechas futuras, ten en cuenta que un turno puede cerrarse un día antes.

Un turno puede tener su propia hora fija de cancelación (del mismo día o del anterior), que reemplaza a la del restaurante para las reservas de ese turno. Convive con las horas antes del turno: gana la que cierre antes, y pasado ese momento la respuesta sigue siendo CANCEL_DEADLINE_PASSED (409).

Qué revisar: Si le anuncias al huésped el plazo de cancelación leyendo booking_policy del restaurante, ten en cuenta que un turno puede tener uno distinto: la respuesta del DELETE es la que manda.

El plano de un restaurante: áreas, mesas numeradas con su posición y capacidad, elementos fijos (barra, fuente, columna…), qué mesas están en servicio en cada turno con el cupo que de ahí se **deriva**, y los metadatos de la imagen de fondo. Dos banderas mandan: has_floor_plan (el restaurante dibujó su sala; sin eso trabaja con tipos y cantidades a mano) y enabled (la organización usa planos). Mismo alcance que GET /restaurants/{id}: no pide permiso extra.

Importa un plano completo en **una sola operación atómica**: o queda todo o no queda nada. Requiere el permiso restaurants.floor_plan (compruébalo en GET /me antes de ofrecer la función). Las áreas se referencian por nombre y las mesas por código, así que no hace falta conocer ningún id antes de importar, y strategy: "merge" es idempotente. **Empieza siempre con dry_run: true**: devuelve el resumen, los avisos y losing_assignment —las reservas futuras que se quedarían sin mesa si replace borra la suya— sin escribir ni una fila. Acepta Idempotency-Key.

Sube, reemplaza o quita la imagen sobre la que se calca el plano, en base64. Límites duros y sin conversión del lado del servidor: 1 MiB de binario, 1600 px por lado y 1.5 MiB de cuerpo; fuera de ahí, el código nuevo PAYLOAD_TOO_LARGE (413) dice qué límite se pasó y cuál es. El tipo se comprueba por el encabezado real del archivo. El binario **entra pero no sale**: ningún endpoint público sirve la imagen.

Código nuevo FLOOR_PLAN_DISABLED (409): la organización o el hotel tiene el plano de sala apagado en sus reglas del negocio. Se responde también en dry_run — un importador que simulara igual mostraría el resumen de algo que nunca va a poder aplicar. La lectura sigue funcionando y devuelve enabled: false.

Objeto booking_policy con la política del restaurante tal como está configurada: same_day_cutoff_time + cutoff_days_before (el corte fijo puede ser del **día anterior**, no solo del mismo día), app_advance_booking_min_minutes, cancel_deadline_hours, cancel_cutoff_time y cancel_cutoff_days_before. Los turnos ya no son la única fuente: el restaurante define el default y el turno solo lo afina — cuando los dos aplican, gana el más exigente.

app_policy_summary pasa a combinar restaurante **y** turnos (antes resumía solo los turnos): min_minutes_before y min_cancel_hours_before son el máximo de las dos capas, y same_day_cutoff_times suma la hora del restaurante cuando es del mismo día. Es un prechequeo orientativo; la verdad de cada fecha sigue siendo GET /restaurants/{id}/availability.

Un restaurante con cutoff_days_before = 1 cierra las reservas de una fecha a la hora fija del **día anterior**: los turnos de esa fecha dejan de listarse antes que antes y el POST responde APP_CUTOFF_PASSED (409). Además, app_advance_booking_min_minutes del **restaurante** ahora se evalúa aunque el turno no lo tenga configurado. Ningún restaurante cambia de comportamiento hasta que el hotel configure esos campos.

Qué revisar: No hay que cambiar código: los códigos de error y el envelope son los mismos. Si cacheas la disponibilidad, revisa que el TTL no sea mayor al corte — y si muestras la política al huésped, léela de booking_policy en vez de derivarla de los turnos.

El plazo de cancelación combina las dos capas: las horas antes del turno (el turno pisa al restaurante) **y** la hora fija cancel_cutoff_time del día que indique cancel_cutoff_days_before. Gana el que cierre antes; pasado ese momento la respuesta sigue siendo CANCEL_DEADLINE_PASSED (409).

Qué revisar: Si le mostrabas al huésped «puedes cancelar hasta N horas antes» calculándolo con app_cancel_deadline_hours del turno, usa booking_policy del restaurante junto con el del turno: con una hora fija configurada, el plazo real puede cerrar antes de lo que decía tu cuenta.

El esquema publicado del listado declaraba cuatro campos (id, name, hotel_id, is_open, adults_only) mientras la respuesta traía además dress_code, max_guests_per_reservation, max_advance_booking_days, app_max_advance_booking_days y app_policy_summary. La doc ya dice exactamente lo que devuelve el endpoint; nada cambió en la respuesta.

El detalle devolvía la política del restaurante en seis campos sueltos y el listado en un objeto booking_policy: dos formas del mismo dato. Ahora el detalle devuelve **también** booking_policy, idéntico al del listado. Los seis campos sueltos siguen ahí y no se van a quitar en v1, pero quedan marcados como deprecados en la doc.

Consultar una fecha **ya pasada** ahora responde RESERVATION_PAST en vez de APP_ADVANCE_VIOLATION. El HTTP sigue siendo **409** y el message no cambia. Eran dos problemas distintos bajo el mismo código: "esa fecha no existe" y "esa fecha está fuera de tu ventana de reserva". El segundo se resuelve proponiendo otra fecha; el primero no se resuelve nunca, y los clientes que ramificaban por el código reintentaban en bucle.

Qué revisar: Si ramificas por el error de este endpoint, agrega RESERVATION_PAST a la rama que ya usas para APP_ADVANCE_VIOLATION. APP_ADVANCE_VIOLATION sigue existiendo, pero ahora significa solo lo que dice: la fecha excede app_max_advance_booking_days. Si no ramificas por código, no tienes que hacer nada.

Cuando el hotel no tiene una integración con PMS activa, la respuesta pasa de INTERNAL_ERROR (HTTP **503**) a PMS_NOT_CONFIGURED (HTTP **409**). No es una falla del servicio: es cómo está configurado ese hotel, y no se arregla reintentando. El 503 decía lo contrario y los clientes reintentaban en bucle.

Qué revisar: Si tu integración reintenta ante 5xx, deja de reintentar POST /opera/lookup para ese hotel: no va a cambiar hasta que el hotel conecte un PMS. Trátalo como 409 permanente y sigue el flujo sin datos de estancia (el huésped los escribe a mano).

Describe la key que llama: organización, hoteles visibles, restaurant_ids, permisos efectivos y límite por minuto. Sirve para validar una integración sin adivinar y es lo que usa el **servidor MCP de Mesatto** para exponer solo las herramientas que la key puede ejecutar.

Header opcional X-Mesatto-Channel: assistant (reservado para asistentes de IA conectados por MCP): la reserva queda con channel='assistant' en reportes y auditoría, con la misma política de la app por turno. Sin el header nada cambia (channel='app'). Los hoteles pueden apagar el canal en Configuración → Canales.

Código ORG_SUSPENDED (HTTP **403**) cuando la organización dueña de la key está suspendida o cancelada (prueba vencida sin plan, pago pendiente por más de 14 días o baja). Se responde en cualquier endpoint, también en lecturas.

Qué revisar: Tratarlo como permanente hasta que el administrador del hotel regularice la suscripción; no reintentar en bucle.

La API corre con la identidad de la **cuenta de servicio** dueña de la key (RLS), no con un rol de servidor: solo se ven la organización, los hoteles y los restaurantes asignados a esa cuenta. Una key puede además acotarse a una lista de restaurantes (restaurant_ids): fuera de ella, restaurantes y disponibilidad responden 404 y crear/modificar reservas responde 403 FORBIDDEN_SCOPE.

Qué revisar: Verificar que la cuenta de servicio tenga acceso a todos los hoteles y restaurantes que la integración usa (panel → Usuarios → cuenta de servicio). Nada cambia si ya lo tenía.

Tres códigos de error nuevos (HTTP **409**), según la configuración de cada hotel: CHANNEL_DISABLED (el hotel apagó el canal app para ese restaurante), STAY_LIMIT_REACHED (la categoría del huésped incluye N visitas por estancia y la habitación ya las usó) y MIN_NIGHTS_NOT_MET (la categoría exige una estancia mínima y check_in_date/check_out_date no la cumplen). Sin esa configuración nada cambia. Cuando el hotel cobra un recargo tras el límite, la reserva se acepta y price/child_price reflejan el recargo.

Qué revisar: Tratar los tres como 409 permanentes para esa reserva (no reintentar igual). Mostrar el message al huésped o localizar por error. Enviar check_in_date/check_out_date cuando se conozcan: sin ellos la estancia se estima por habitación en una ventana de ±7 días.

Rate limit por **plan de la organización** (Retry-After y X-RateLimit-* en el 429): 60/min en prueba, 300 starter, 1,000 pro, 5,000 enterprise, siempre por debajo del techo global de la plataforma.

Qué revisar: Respetar Retry-After en 429 y cachear catálogos; si el plan queda corto, se ajusta desde la plataforma.

Los destinos deben ser **https://** y resolver a direcciones públicas; se verifica al guardar y en cada entrega, y no se siguen redirecciones (un 3xx cuenta como fallo). Un destino privado o interno marca la entrega como fallida sin reintentos.

Qué revisar: Publicar el receptor en un host público con TLS. Sin cambios si ya era así.

Las cabeceras pasan a X-Mesatto-Event, X-Mesatto-Delivery-Id y X-Mesatto-Signature (mismo HMAC-SHA256 del body), User-Agent: Mesatto-Webhook/2.0, y el envelope incluye version: 2. No hay periodo de doble cabecera: no existen suscripciones activas anteriores a este cambio.

Qué revisar: Leer la firma desde X-Mesatto-Signature. El cálculo del HMAC no cambia.

Fechas y cortes (APP_CUTOFF_PASSED, antelación) se evalúan en la **zona horaria del hotel** de la reserva, no en una zona única de plataforma.

Qué revisar: Ninguna si operas un solo hotel. Con hoteles en zonas distintas, no asumas una misma hora de corte para todos.

Paginación por **cursor** (keyset): la primera página se pide sin parámetros nuevos y ahora incluye meta.next_cursor (string opaco, o null si no hay más páginas); las siguientes se piden con cursor=<meta.next_cursor> manteniendo los mismos filtros. En modo cursor la respuesta trae meta { limit, has_more, next_cursor } — sin total ni offset (el total se informa una vez, en la primera página). A diferencia de offset, el cursor **no duplica ni omite filas** cuando se crean o cancelan reservas entre página y página. El cursor es opaco: úsalo tal cual, sin parsearlo ni fabricarlo. Código de error nuevo INVALID_CURSOR (HTTP **422**) para cursors malformados — la recuperación es reiniciar la paginación sin cursor.

offset queda **deprecated**. Sigue funcionando exactamente igual que hasta ahora y **no hay fecha de remoción** — cuando la haya, se avisará con antelación por este canal. cursor y offset juntos en el mismo request responden 422 VALIDATION_ERROR (son excluyentes).

Qué revisar: Sin urgencia: nada se rompe hoy. Recomendado migrar a cursor cuando toques ese código — es más eficiente del lado del servidor y elimina los duplicados/salteos entre páginas.

El orden del listado ahora es **determinístico**: las reservas con la misma fecha+hora se devuelven en orden estable entre requests (desempate interno por id). Antes el orden entre esos empates era indefinido y podía variar de un request al siguiente — en el borde de página, eso podía duplicar u omitir filas al paginar con offset.

Qué revisar: Si tu integración dependía del orden relativo entre reservas con la misma fecha+hora, revísala: el orden es estable a partir de este cambio, pero puede ser distinto del que venías observando. Si no depende de eso (lo habitual), no hay nada que hacer.

Los campos release_minutes (del restaurante y de cada turno), que la API ya exponía, **ahora se evalúan**: cada turno deja de aceptar reservas para HOY esos minutos antes de su start_time. El corte efectivo de un turno es el **más temprano** entre este release y los cutoffs absolutos ya vigentes (same_day_cutoff_time del restaurante y app_same_day_cutoff_time del turno). Pasado el corte, GET .../availability deja de listar ese turno para HOY, y el POST (o un PATCH que mueva la reserva a ese turno) responde APP_CUTOFF_PASSED (HTTP **409**) — el mismo código del cutoff absoluto. A diferencia del cutoff por restaurante, esto rige DESDE EL DESPLIEGUE: los turnos ya tienen 5-10 minutos configurados por el hotel, así que la disponibilidad de última hora que veías hasta ahora (reservar un turno ya empezado) desaparece. Las fechas futuras no cambian en ningún caso.

Qué revisar: Nada que cambiar en el código si ya tratas APP_CUTOFF_PASSED como un 409 permanente del día (recomendación del aviso de agosto). Revisa cachés de availability: un turno que a las 17:50 aparecía listado puede no estar a las 17:56. GET /api/v1/restaurants/{id} y los turnos de availability ya exponen release_minutes — puedes anticipar el cierre en tu UI en vez de esperar el 409.

El hotel puede configurar, por restaurante, una **hora fija a partir de la cual no se aceptan reservas para el mismo día** (same_day_cutoff_time, en la zona horaria del hotel). A diferencia del cutoff que ya existía por turno —que solo aplicaba a este canal— este aplica a **todos los turnos del restaurante y a todos los canales**, incluido el panel del concierge. Pasada esa hora, GET .../availability deja de listar los turnos de HOY (puede devolver data vacío) y el POST los rechaza con APP_CUTOFF_PASSED (HTTP **409**). Cuando conviven el cutoff del restaurante y el del turno, **gana el más temprano**. El campo se expone en GET /api/v1/restaurants/{id} como same_day_cutoff_time (null = sin cutoff). Es opt-in: mientras el hotel no configure una hora, nada cambia.

Qué revisar: Trata APP_CUTOFF_PASSED como un 409 permanente, sin reintentos — volver a intentar el mismo día no va a funcionar. Un data vacío en availability para HOY ya no significa necesariamente que el restaurante esté lleno o cerrado: puede ser el cutoff. Si muestras horarios cacheados, refresca availability antes de confirmar. Copy sugerido para el huésped: «Las reservas para hoy en este restaurante ya cerraron. Elige otra fecha.»

Campo nuevo same_day_cutoff_time (string HH:MM:SS o null) con la hora de cierre de reservas del mismo día. Sirve para anticiparle al huésped el corte antes de que intente reservar, en vez de esperar el 409.

El hotel definió que una habitación solo puede tener una reserva de restaurante activa por día, **en todos los restaurantes del hotel**. Hasta ahora la regla existía solo cuando la reserva traía opera_reservation_id; a partir de este cambio se evalúa también por número de habitación, así que puede rechazarse una reserva que antes pasaba: por ejemplo, si esa habitación ya tiene una reserva cargada por el concierge en otro restaurante. La respuesta trae el código RESERVATION_DUPLICATE_ROOM (HTTP **409**) con message bilingüe (español y luego inglés) listo para mostrarle al huésped. La regla solo se evalúa cuando la reserva lleva room_number; si se omite el campo, no aplica.

Qué revisar: Trata RESERVATION_DUPLICATE_ROOM como un 409 permanente, sin reintentos, igual que RESERVATION_DUPLICATE_DAY. Si tu flujo permite elegir restaurante, conviene avisarle al huésped que ya tiene una reserva ese día antes de llegar al error. Recomendado: sigue enviando room_number siempre (hoy lo haces en el 100% de los casos) — es lo que permite detectar el choque.

El enum error del schema ApiError en el spec OpenAPI omitía RESERVATION_DUPLICATE_DAY, aunque la API lo emite desde el 2026-07-29 (ver la entrada de esa fecha). Solo se corrige la documentación — el comportamiento de la API no cambia.

Cuando el huésped ya tiene una reserva de restaurante activa ese día (una reserva por día y por habitación), la respuesta ahora trae el código semántico RESERVATION_DUPLICATE_DAY (HTTP **409**). Antes esta regla salía como **500** sin código estable. Además, el message de este caso y el de APP_QUOTA_EXCEEDED vienen **bilingües** (español y luego inglés, separados por línea en blanco), listos para mostrarle al huésped. El PATCH también aplica esta validación al mover una reserva a una fecha con colisión (antes devolvía el error crudo de la base de datos).

Qué revisar: Si tratabas el 500 de este caso como error de servidor con reintentos, cámbialo: es un 409 permanente con código RESERVATION_DUPLICATE_DAY. Recomendado: localiza tu propio copy contra el error code; si prefieres, el message ya viene en ES + EN.

Antes solo se rechazaba EDITAR una reserva cuya fecha ya había pasado. Ahora también se rechaza MOVER una reserva vigente hacia una fecha anterior a hoy (zona horaria del hotel, America/Cancun): responde RESERVATION_PAST (409). Mover a hoy o al futuro sigue permitido.

Qué revisar: Si tu app permite cambiar la fecha de una reserva, no ofrezcas fechas anteriores a hoy — el 409 RESERVATION_PAST ya cubría editar reservas pasadas; ahora también cubre el date de destino.

opera_reservation_id pasa a ser OPCIONAL en el ownership claim. Para una reserva creada **sin** ese campo, la identidad ahora se prueba con que la reserva la haya creado TU API key vía este canal (antes esas reservas quedaban inalcanzables: no existía valor que satisficiera el claim). Las reservas que SÍ tienen opera_reservation_id siguen exigiéndolo — el comportamiento existente no cambia. En el listado, omitir el parámetro devuelve solo tus reservas huérfanas de opera_reservation_id.

Qué revisar: Nada que cambiar si siempre envías opera_reservation_id (recomendado). Si creas reservas sin él, ahora puedes leerlas/editarlas/cancelarlas omitiendo ese campo del claim. Ojo: la identidad del fallback es TU service account — si algún día se migra a un service account nuevo, las reservas huérfanas del anterior dejan de ser alcanzables.

El hotel puede topar cuánta capacidad diaria de un restaurante ocupa cada integrador. Donde haya tope configurado, el remaining de cada turno viene limitado por lo que te queda de cuota ese día, y la respuesta trae un objeto meta con quota_exhausted, quota_limit_pax, quota_used_pax y quota_remaining_pax. Al agotarse la cuota, data viene vacío con meta.quota_exhausted: true. **Por defecto ningún restaurante tiene tope**: mientras el hotel no active uno, nada cambia.

Qué revisar: No trates un data vacío como error ni como restaurante cerrado: revisa meta.quota_exhausted. Si es true, muéstrale al huésped que no hay disponibilidad para esa fecha por tu canal y ofrécele otra fecha.

Si la reserva no entra en la cuota que te queda ese día en ese restaurante, se rechaza con APP_QUOTA_EXCEEDED (409). Cancelar una reserva libera cuota automáticamente.

Qué revisar: Maneja APP_QUOTA_EXCEEDED como un 409 más. El mensaje sugerido al huésped es: «No hay disponibilidad para esta fecha en este canal. Intenta con otra fecha.»

El flag fits ahora exige, además de cupo de personas (remaining >= pax), que exista un acomodo de mesas posible. Antes solo miraba el cupo, así que devolvía true para grupos que el POST /api/v1/reservations rechazaba después con RESERVATION_TABLES_FULL.

Qué revisar: Si filtras turnos por remaining >= pax, cambia a fits === true. El resultado neto es que verás menos turnos ofrecidos, pero los que se ofrecen sí aceptan la reserva.

Campo max_available_single_table_capacity por turno: capacidad de la mesa individual más grande que sigue libre. null = el turno no tiene mesas configuradas (solo aplica el cupo); 0 = no queda ninguna mesa individual libre y habría que combinar.

Se valida el calendario del turno: días de la semana en que aplica, vigencia (fecha de inicio/fin) y turno activo. Antes solo se filtraba al listar disponibilidad, así que era posible crear o mover una reserva a un día en que el restaurante no abre. Rechaza con SEATING_UNAVAILABLE (409).

Qué revisar: Usa siempre los turnos que devuelve el endpoint de disponibilidad para esa fecha; no reutilices un seating_id de otra fecha.

Las reservas de fechas pasadas ya no se pueden editar: responde RESERVATION_PAST (409). Cancelar una reserva pasada sigue disponible.

Qué revisar: Si tu app permite editar el histórico, deshabilita la edición para reservas con fecha anterior a hoy (zona horaria del hotel, America/Cancun).

El seating_id enviado debe pertenecer al mismo restaurante de la reserva. Antes un turno de otro restaurante pasaba la validación y dejaba la reserva en un estado inconsistente. Rechaza con VALIDATION_ERROR (422).

Campos adult_count y child_count dentro de guest: la ocupación registrada en Opera para esa habitación. Vienen null si el PMS no los informa.

Qué revisar: Opcional: úsalos para precargar el número de comensales (guests = adult_count + child_count) en vez de pedirlo desde cero.

Campo adults_only (boolean): el restaurante admite solo adultos (18+). La API **no** rechaza reservas con menores por este flag — es informativo.

Qué revisar: Muestra el aviso al huésped antes de confirmar la reserva en restaurantes con adults_only: true.

Códigos de error nuevos: SEATING_UNAVAILABLE y RESERVATION_PAST (ambos HTTP 409).

Qué revisar: Agrégalos a tu manejo de errores. Son condiciones permanentes: no tiene sentido reintentar la misma request.

El campo currency devolvía siempre null por leer una columna equivocada. Ahora trae la moneda configurada (el listado ya la devolvía bien).

Varias reglas de negocio respondían HTTP 500 INTERNAL_ERROR en lugar de un 409 con código semántico, lo que sugería una falla transitoria y invitaba a reintentar. Ahora devuelven el código correcto.

Nombres de turno (seating.name) que habían quedado desincronizados de su hora real tras editarlos (p. ej. mostraba 14:00 con hora real 15:00).