Integración de ICNEA con tu web y con tu operativa

Qué se puede conectar de ICNEA

ICNEA no expone una sola API, expone varias puertas con dialectos distintos. Por una se consulta el escaparate (lo que necesita una web para buscar y vender), por otra se consultan las reservas del negocio con nombre, teléfono y correo. Sabiendo cuál es cuál, esto es lo que se puede sacar y meter en tu web y en tu operativa.

• Disponibilidad real por fechas y personas, para que la web enseñe lo que de verdad está libre en ese momento.
• Tarifas por día y por casa, con la estancia mínima y los cierres a entrada y salida, que viven en una llamada distinta a la de disponibilidad.
• Ocupación por casa: las noches no disponibles, que incluyen reservas y también bloqueos del propietario y cierres por mantenimiento.
• Reservas del negocio: entradas, salidas, estado, importe de la estancia, nombre, teléfono y correo del huésped.
• Aforo real de cada reserva, sumando adultos, niños y bebés, que llegan en tres campos separados.
• El enlace de check-in del huésped, que hasta ahora había que abrir el programa y copiar a mano reserva a reserva.
• El inventario de casas, con sus fotos y su ficha, para llevar al cliente desde tu buscador a la ficha con sus fechas ya puestas.
• Sobre eso: cuadrante de limpiezas por salidas, avisos de entrada, portal del huésped, accesos con código y listados de ocupación.

ICNEA no tiene sesión: cada llamada lleva la contraseña

No hay login, ni token, ni cookie, ni caducidad. Cada petición viaja con el usuario y la contraseña dentro. Y no en un sitio: en la API del escaparate son dos campos de formulario, y en la API Owners van dentro del XML del cuerpo. Además hay dos juegos de credenciales que se confunden a diario: el usuario numérico con su clave de API, y el correo con la contraseña con la que entras a tu programa. El segundo no sirve para la API. El peligro de verdad es otro: todos los verbos aceptan también peticiones por GET. Si alguien llama así, la contraseña acaba escrita en la URL, en los registros del proxy, en el historial del navegador y en cualquier traza de error. Por eso todas las llamadas van por POST, siempre desde el servidor y nunca desde el navegador del visitante, con la contraseña en un almacén de secretos que se lee en el momento de llamar y no dentro del código.

El error llega con HTTP 200: por eso el calendario sale vacío

Ni la API Owners ni el motor del escaparate usan los códigos de estado para los errores de negocio. Una credencial mala contesta 200. Un permiso que falta contesta 200. El error va dentro del cuerpo: en un caso una etiqueta ko con el texto, en el otro un mensaje suelto sin el campo que trae siempre la respuesta buena. Si el cliente solo mira si la respuesta fue correcta, el fallo se cuela como una respuesta vacía: cero alojamientos, cero reservas, cero noches ocupadas. Y el sistema se queda tan tranquilo pintando un calendario en blanco en plena temporada alta, marcado como sano. Hay dos errores que parecen el mismo y no lo son. Uno dice que el usuario es incorrecto: la contraseña no vale. El otro dice que el usuario no está autorizado: las credenciales son buenas, pero ese verbo todavía no está abierto para tu cuenta, que es exactamente lo que pasa mientras ICNEA te los va habilitando de uno en uno. Distinguirlos es la diferencia entre llamar a ICNEA o revisar la configuración, así que el texto literal del proveedor se guarda tal cual en el registro, sin traducir ni normalizar.

Lo que dice su documentación y lo que manda su servidor

Esta es la trampa que más caro sale y la razón por la que una integración con ICNEA no se programa contra el manual. La documentación describe las fechas de ocupación en formato internacional, con el año delante. El servidor real las manda al revés, con el día delante. La primera versión de un calendario de ocupación descartó esas cadenas como basura y enseñó cero noches ocupadas en agosto, sin lanzar un solo error. Igual pasa al revés: el servidor manda campos valiosos que el esquema publicado ni menciona, entre ellos la fecha de salida en el índice, el importe de la estancia, el acrónimo interno de la casa y el enlace de check-in del huésped. Programar por la documentación deja fuera justo lo que hace útil la integración. El método que uso es simple y no tiene atajo: una llamada real por cada verbo contra tu cuenta, volcar la respuesta entera y sacar el esquema de lo que llega. Esa respuesta capturada del cable, con su envoltorio y sin retocar un campo, se queda como caso de prueba. Así se cazó lo de las cero noches.

Las canceladas no salen por la puerta de las llegadas

El índice de reservas por fecha de llegada devuelve lo que entra en la ventana que pidas, pero nunca las canceladas. Quien sincronice solo por ahí acumula reservas muertas vivas para siempre: la casa figura ocupada, el cuadrante fabrica una salida que no existe y el huésped conserva su acceso a la vivienda. Las cancelaciones entran por otra puerta, el índice por fecha de alta, que además devuelve reservas tocadas aunque se dieran de alta hace meses. No es lo dado de alta: es lo que se ha movido. Por eso cada pasada hace dos preguntas y funde los resultados por número de reserva antes de procesar nada. La foto del futuro viene de una; los cambios y las bajas, de la otra, con una ventana corta hacia atrás. Y hay un detalle más en el detalle de cada reserva: no trae fecha de entrada ni de salida, trae la lista de noches. La entrada es el primer día y la salida es el último más uno, porque la última noche dormida no es el día que se marcha. Quien tome el último día como salida deja todas las estancias un día cortas: la limpieza se programa el día equivocado y el acceso del huésped se cierra la noche antes de irse.

Cuando ICNEA no contesta, no se toca nada

Es el fallo más caro y no da ningún error. Si una consulta se corta a mitad y el sistema procesa lo que llegó, todo lo que no vino parece haber desaparecido. Una sincronización lista de más lo interpreta como cancelaciones: vacía el calendario, cancela las limpiezas del día y mata los accesos de huéspedes que están dentro de la casa en ese momento. La regla es explícita y no se negocia. Si la consulta falla, se aborta la pasada entera y no se escribe una sola línea; la siguiente lo arreglará. En la generación del cuadrante, si la capa de ocupación no ha contestado ese día no se cancela nada nacido de ella: mejor una tarea de más que un cuadrante amanecido en blanco por una API con hipo. Y una reserva concreta cuyo detalle no responda se salta con aviso, sin tumbar el barrido de las demás. Del mismo modo, una cancelación no borra la reserva: la marca como revocada. El acceso del huésped muere al instante, pero queda el rastro. Si en el PMS revierten la cancelación, y pasa, la reserva vuelve a estar viva con su mismo enlace en lugar de nacer de cero y dejar muerto el que el huésped ya tenía en el móvil.

Qué gana el negocio

La parte técnica solo importa por lo que sostiene. Estas son las tres cosas que cambian en el día a día cuando ICNEA y tu web hablan bien.

• Reserva directa sin comisión de portal: tu web busca contra la disponibilidad real, enseña la tarifa y lleva al cliente a reservar contigo. El cliente que te busca por el nombre de la casa deja de irse a un portal a pagar un recargo.
• Calendario único que evita dobles reservas: la verdad vive en ICNEA y todo lo demás lee de ahí. La web no vende sobre una copia vieja, y las noches bloqueadas por el propietario o por mantenimiento se ven igual que las reservadas.
• Operativa cuadrada: el cuadrante de limpiezas nace de las salidas reales, con la fecha bien calculada, y los accesos del huésped se abren y se cierran con la estancia. El enlace de check-in deja de copiarse a mano reserva a reserva.
• Quien atiende el teléfono, persona o asistente, encuentra al huésped que acaba de reservar, porque la reserva llega en minutos y no a la noche siguiente.
• El histórico del negocio deja de estar preso en el programa: se importa una vez y sirve para mirar ocupación y estacionalidad con tus propias herramientas.

Cómo trabajo una integración con ICNEA

Empezamos llamando a tu cuenta de verdad y viendo qué contesta, verbo por verbo, antes de escribir una línea de adaptador. Con eso sabemos qué tienes abierto y qué hay que pedirle a ICNEA. Antes de guardar las credenciales hacemos una llamada de prueba: si no contesta, no se guardan y la integración queda marcada en error con el motivo, porque una integración que dice conectada y pinta en blanco es peor que una que dice que no está conectada. Esa misma prueba se repite sola cada pocas horas para enterarnos de una rotura del proveedor antes que el cliente. El catálogo de casas manda: se casa desde tus fichas hacia el identificador de ICNEA, y lo que no case se descarta contando cuántas fueron, nunca en silencio. Así no entran en tu sistema los pseudoalojamientos que ICNEA usa como calendario interno ni las propiedades que ya no llevas. Y desde la reserva, todo es lectura: lo que es verdad en el PMS se corrige en el PMS. Trabajamos así en todos los proyectos con sistemas ajenos de por medio, sean PMS, pasarelas de pago o software de gestión, y con productos propios como SILICIE VapeTax y Tictacdicta. Con BalMY Spain, que autoriza citarlo, el planteamiento es el mismo: leer lo que el sistema contesta de verdad y no romper nada cuando deja de contestar.

Preguntas frecuentes