Check-ins

Idempotente: si el check-in ya existe, responde 200 con el existente (campo created: false) y la misma URL. Reintenta con libertad. El segundo envío no modifica la reserva que ya había: para cambiarle las fechas, la plantilla, las normas o el método de pago, PATCH.

Del returnUrl comprobamos la forma, no que funcione. Que sea https y no lleve credenciales dentro; ahí se acaba. No la visitamos ni verificamos que exista, porque en el momento de crear la reserva puede aún no existir y porque abrir conexiones a direcciones que nos dictan desde fuera es un riesgo que no vale lo que aporta.

La consecuencia práctica: una URL bien formada pero incompleta se acepta sin protestar y falla al final, cuando el huésped ya ha terminado, pulsa para volver y aterriza en un 404. Pasa con las direcciones que llevan un token o un identificador en el último tramo y se construyen a trozos — …/booking/R-2026-0412 en vez de …/booking/R-2026-0412/f9K2xQ—. Mándala entera, con el token incluido, y pruébala pegándola en el navegador antes de integrarla.

Un houseRulesId que apunta a un juego borrado, o a uno que se quedó sin texto en ningún idioma, no corta la cadena: se sigue por el candidato siguiente. Un borrado hecho meses después no puede dejar sin normas a las reservas que ya lo tenían asignado.

Códigos válidos: EFECT, TARJT, PLATF, TRANS, MOVIL, DESTI, TREG y OTRO — la tabla con su significado está en Credenciales SES. El valor se lee al construir el parte, no al crear la reserva: un PATCH antes del envío cambia lo que se comunica. Después, cambiar solo el método de pago no rehace lo comunicado; cambiar las fechas sí, y la comunicación nueva sale con el valor vigente.

Elegir el contrato según la duración de la estancia. Si tu normativa autonómica distingue regímenes por duración —en la Comunidad Valenciana, más de 10 días deja de ser vivienda de uso turístico y pasa a arrendamiento de temporada bajo la LAU—, la decisión la toma tu sistema, que es quien conoce tu caso y su interpretación legal:

contractTemplateId = noches > 10 ? PLANTILLA_TEMPORADA : PLANTILLA_TURISTICO

Y si la reserva se alarga y cruza el umbral, el mismo PATCH que cambia las fechas puede cambiar el contrato. En el panel, cada reserva muestra sus noches, su idioma y qué plantilla tiene asignada, para que puedas comprobar que tu lógica hizo lo que esperabas.

Cambiar las fechas de una reserva ya comunicada la vuelve a comunicar. SES Hospedajes no tiene operación de modificación —solo alta, consulta y anulación— y el parte lleva las fechas dentro. Si mueves la entrada o la salida de una reserva cuyo parte ya salió, Kinapi anula esa comunicación ante el Ministerio y la vuelve a dar de alta con los huéspedes que ya tenía: en el acto si la nueva entrada es hoy o ya pasó, y si es futura, en el envío nocturno de esa noche, como cualquier otra reserva.

Primero se anula y solo después se guarda. Si la anulación no sale, la reserva se queda como estaba, aquí y en el Ministerio, y la respuesta lo dice: nunca quedan fechas nuevas en Kinapi y viejas en SES. Solo las fechas disparan esto; las horas, el número de huéspedes o el método de pago se guardan sin tocar lo comunicado.

Dentro del enlace, los campos que identifican a una persona —número de documento, número de soporte y fecha de nacimiento— solo se muestran a quien la registró, y durante unas horas. Después se pueden corregir, pero no leer: el resto del grupo ve el documento enmascarado. Es lo que evita que un enlace reenviado sirva para consultar los datos de un tercero.

Si el parte de esa reserva ya se había comunicado —el caso comunicado, que siempre acaba en cancelación—, Kinapi lo anula ante SES Hospedajes en la misma llamada: el art. 6.3 del RD 933/2021 obliga a comunicar también la anulación, y sin eso en el Ministerio seguiría constando una estancia que no va a ocurrir. La respuesta trae ses.anulados con cuántas comunicaciones se anularon, y ses.anulacionError si el Ministerio no aceptó la anulación. La reserva queda cancelada igualmente y Kinapi reintenta la anulación cada hora, hasta 72 intentos (tres días); si no lo consigue, emite el webhook ses.cancel_failed. También puedes repetir el DELETE para reintentarla en el acto. Cuando el Ministerio acepta la anulación se emite el webhook ses.cancelled con reason: "cancelled". En el caso deleted no hay nada que anular por definición.

Cancelada con el parte en vuelo. Si el parte estaba enviado y SES aún no lo había confirmado, todavía no se puede anular: para el Ministerio aún no existe. La reserva se cancela igual, y en cuanto llega la confirmación Kinapi anula esas comunicaciones; la reserva sigue en cancelled.

Aceptar una anulación no es procesarla. SES procesa las anulaciones de forma asíncrona, como las altas: Kinapi consulta cada hora el lote de anulación y, si el Ministerio la rechazó, emite ses.cancel_failed. La comunicación sigue constando y hay que revisarla en SES.HOSPEDAJES. El estado de cada anulación está en el campo annulment de GET /checkins/{reservationId}/ses.