Purple Portal API: What You Can Do With It

Una referencia técnica para directores de TI y arquitectos de red sobre cómo aprovechar la Purple Portal API. Esta guía detalla los endpoints disponibles, la autenticación y los casos de uso reales para integrar los datos de WiFi de invitados con los sistemas empresariales para mejorar la inteligencia empresarial y la eficiencia operativa. Cubre tanto los patrones de integración de REST API como de Webhook, con casos de estudio concretos de los sectores de hostelería, retail y eventos.

📖 9 min de lectura📝 2,212 palabras🔧 2 ejemplos prácticos❓ 3 preguntas de práctica📚 9 definiciones clave

Escuchar esta guía

Ver transcripción del podcast

Le damos la bienvenida a la sesión informativa técnica de Purple. Soy estratega sénior de contenido aquí en Purple y, en los próximos diez minutos, le ofreceré una descripción general, concisa y práctica, de nuestra Portal API: qué es, qué puede hacer con ella y cómo aprovecharla para lograr el máximo impacto empresarial. Esto está dirigido a los responsables de TI, arquitectos y directores de operaciones que necesitan saber cómo transformar su WiFi para invitados de un simple servicio a un potente activo de datos.

Comencemos con el contexto. Dispone de WiFi para invitados en todos sus establecimientos. Cada día se conectan cientos o miles de personas. Facilitan su correo electrónico, tal vez su nombre, y aceptan sus condiciones. Se trata de valiosos datos de origen (first-party data). El portal de Purple le ofrece excelentes paneles para visualizar esto, pero el verdadero potencial surge cuando conecta esos datos con el resto de su ecosistema empresarial. Ahí es donde entra en juego la Portal API. Es el puente que permite a sus sistemas comunicarse con nuestra plataforma de forma programática.

Ahora, entremos en los detalles técnicos. La Portal API es una interfaz RESTful estándar. La autenticación es sencilla y segura, mediante una API Key directa. No tiene que preocuparse por complejos flujos de autorización OAuth para la comunicación de servidor a servidor. Un aspecto fundamental es que no existen límites de frecuencia (rate limits). La hemos diseñado para una escala empresarial, por lo que, tanto si gestiona un único hotel como una cadena nacional de quinientas tiendas minoristas, la API puede soportar su volumen de datos.

Dispone de dos formas principales para extraer datos. En primer lugar, el método de extracción (pull): endpoints REST estándar. Piense en endpoints como "visitors" (visitantes) y "venues" (establecimientos). Puede programar un script para llamar a estos endpoints de forma periódica, extraer todos los datos de los visitantes de las últimas veinticuatro horas y cargarlos en su almacén de datos para su análisis. Esta es la opción ideal para la inteligencia empresarial, para crear esos paneles de visión global en Power BI o Tableau.

Pero la parte realmente interesante es el método de inserción (push): Webhooks. Esto es para el tiempo real. Usted configura un endpoint de escucha en su lado y, en el momento en que un invitado se autentica en su WiFi, le enviamos un payload JSON con todos sus detalles: nombre, correo electrónico, en qué establecimiento se encuentra, su número de visitas e incluso el método de autenticación que ha utilizado, ya sea un formulario de registro, inicio de sesión social u otro. Es casi instantáneo. Esto es lo que permite una interacción inmediata y personalizada. Es la diferencia entre enviar un correo electrónico de marketing mañana o enviar una notificación de bienvenida con una oferta exclusiva en el preciso instante en que un cliente habitual cruza su puerta.

Permítame hablar de los campos de datos que obtiene. El payload del Webhook está estructurado en cuatro objetos principales. El objeto client le proporciona la dirección MAC y el user agent. Los objetos company y venue le ofrecen los identificadores y las coordenadas geográficas de la ubicación específica. El objeto session le proporciona la marca de tiempo de autenticación. Y el objeto user es donde está el verdadero valor: nombre, apellidos, correo electrónico, género, fecha de nacimiento, número de móvil, código postal y un recuento de visitas por venue que muestra las fechas de la primera y la última visita. También puede capturar campos personalizados del formulario de registro de su Captive Portal, de modo que si solicita a los huéspedes su número de programa de fidelización o su número de habitación en un hotel, eso también se transmite.

Ahora, en la versión uno punto siete de la API, hay una mejora importante que vale la pena señalar. El campo unsubscribed ahora distingue claramente entre los usuarios que optaron activamente por no recibir marketing después de haber estado suscritos previamente, frente a aquellos que simplemente nunca optaron por participar. Esto es fundamental para el cumplimiento del GDPR y para una segmentación precisa. No querrá tratar a un suscriptor inactivo de la misma manera que a alguien que nunca estuvo en su embudo de marketing.

Hablemos de los patrones de integración con más detalle. Para el patrón de extracción de la REST API, su flujo de trabajo típico es un script programado, tal vez en Python o Node.js, que se ejecuta por la noche. Se autentica con su clave de API, consulta el endpoint de visitantes para cada venue, transforma los datos al formato requerido y los carga en una base de datos central. Este es un proceso ETL clásico. Para un operador de múltiples sitios, iteraría a través de sus ID de venue y agregaría los datos de forma centralizada.

Para el patrón de inserción de Webhook, la arquitectura es ligeramente diferente. Necesita un endpoint accesible públicamente y protegido por SSL. Una función serverless es ideal aquí: AWS Lambda, Azure Functions o Google Cloud Functions. Es rentable, se escala automáticamente y gestiona la concurrencia que vería en un venue con mucha actividad. Cuando la función recibe la solicitud POST de Purple, debe analizar el JSON, realizar su lógica de negocio (tal vez una búsqueda en el CRM o una comprobación de fidelización) y devolver una respuesta de doscientos OK lo más rápido posible.

Esto me lleva al requisito de implementación más importante: su listener debe responder en un plazo de diez segundos. Si no lo hace, Purple volverá a poner en cola la solicitud y lo reintentará después de tres horas. Los fallos persistentes harán que el Webhook se desactive automáticamente por motivos de seguridad. Así que mantenga su listener ligero. Realice el procesamiento mínimo necesario para devolver una respuesta rápida y, si necesita realizar un procesamiento pesado, envíe el evento a una cola interna y procéselo de forma asíncrona.

Ahora veamos algunos escenarios del mundo real para concretar esto.

Piense en un hotel de doscientas habitaciones. Quieren incorporar automáticamente a los nuevos huéspedes de WiFi en un flujo de correos electrónicos de bienvenida en su plataforma de marketing. La solución es sencilla: configurar un Webhook, crear un receptor serverless simple y, cuando lleguen los datos de un nuevo usuario, comprobar si ya existe en la plataforma de marketing. Si no es así, añadirlo y activar el flujo de bienvenida. El hotel también puede utilizar el campo de recuento de visitas para distinguir a los visitantes que vienen por primera vez de los que regresan, y adaptar la comunicación en consecuencia. Un huésped que regresa podría recibir una oferta de recompensa por fidelidad en lugar de una bienvenida genérica.

Ahora piense en una cadena de tiendas minoristas nacional con cincuenta establecimientos. Quieren un panel centralizado que muestre las tendencias de tráfico de personas en todas las ubicaciones. En este caso, el patrón de extracción de la REST API es la opción adecuada. Un script nocturno consulta el endpoint de visitantes para cada uno de los cincuenta locales, agrega los datos y los carga en un almacén de datos. A continuación, el equipo de análisis crea sus paneles sobre esta base. Pueden ver qué tiendas tienen las tasas más altas de nuevos visitantes, cuáles tienen los mejores ratios de visitantes recurrentes y cómo se correlacionan los tiempos de permanencia con el rendimiento de las ventas.

Permítame ahora abordar algunos errores comunes y cómo evitarlos.

El primer error es la gestión de eventos duplicados. La visita de un solo huésped puede activar múltiples eventos de autenticación; por ejemplo, si se bloquea la pantalla de su teléfono y este se vuelve a conectar, o si realiza roaming entre puntos de acceso. Su receptor debe ser idempotente. Antes de realizar una acción como enviar un correo electrónico, compruebe si ya ha procesado un evento para ese usuario hoy.

El segundo error es no validar la URL de su receptor antes de la puesta en marcha. Purple requiere que valide el endpoint en el portal antes de que pueda recibir datos. Asegúrese de que su receptor esté activo y devuelva la cabecera wifiWebhookListener correcta antes de asociarlo a un LogicFlow.

El tercer error es ignorar el estado de suscripción. Compruebe siempre el campo de no suscrito antes de añadir a un usuario a una lista de marketing. Enviar comunicaciones de marketing a alguien que ha optado por no recibirlas es una infracción del GDPR con consecuencias significativas.

Pasemos ahora a una sesión rápida de preguntas y respuestas.

¿Puedo sincronizar esto con mi CRM personalizado? Sí. Si su CRM dispone de una API, puede utilizar un receptor de Webhook como middleware para dar formato a los datos de Purple e introducirlos en su sistema. Los ID devueltos en la carga útil del Webhook coinciden con los de la REST API, por lo que también puede realizar llamadas de seguimiento para obtener detalles adicionales si es necesario.

¿Cómo gestiono a un usuario que visita varios centros de mi propiedad? La API proporciona recuentos de visitas por ID de local, por lo que puede realizar fácilmente un seguimiento del recorrido de un cliente por toda su propiedad y crear un perfil completo de múltiples sitios.

¿Existe un límite en el número de URL de Webhook que puedo configurar? No. Puede validar y utilizar tantas URL de receptor como necesite, lo cual resulta útil si diferentes equipos o sistemas necesitan recibir los mismos datos de eventos.

¿Qué ocurre si mi receptor se cae por mantenimiento? Purple volverá a intentar los envíos fallidos, por lo que es posible que reciba una acumulación de eventos pendientes cuando su receptor vuelva a estar en línea. Su receptor debe gestionar esto de forma fluida, procesando los eventos que puedan llegar fuera del orden cronológico.

Para resumir todo lo que hemos tratado hoy, la API del portal de Purple es la clave para desbloquear el inmenso valor de los datos de su WiFi de invitados. Utilice la REST API para extraer datos para informes y análisis. Utilice Webhooks para enviar datos en tiempo real para una interacción inmediata y personalizada con el cliente. Recuerde el principio clave: push para tiempo real, pull para informes.

El siguiente paso es revisar la documentación de la API en nuestro portal de soporte. Si dispone de una licencia Engage, genere una clave de API y empiece a explorar con Postman. Cree un receptor de Webhook sencillo. Observe cómo fluyen los datos. Ese es el momento en que el potencial de esta herramienta se vuelve totalmente evidente.

Gracias por escuchar el Informe Técnico de Purple. Si desea hablar con uno de nuestros arquitectos de soluciones sobre sus requisitos específicos de integración, visite purple dot ai y reserve una demostración. Hasta la próxima.

Conclusiones clave

✓La API de Purple Portal proporciona acceso programático a los datos de WiFi de invitados mediante una autenticación sencilla por API Key, sin límites de velocidad (rate limits).
✓Requiere una licencia Engage y actualmente funciona con la versión v1.7, que mejoró el cumplimiento de GDPR mediante una gestión más clara del estado de baja de suscripción.
✓Utiliza la REST API (pull) para exportaciones de datos por lotes, procesos ETL y paneles de análisis.
✓Utiliza Webhooks (push) para acciones en tiempo real basadas en eventos, como sincronizaciones de CRM, mensajería personalizada y activadores de fidelización.
✓Los receptores de Webhooks deben estar protegidos por SSL, responder en un plazo de 10 segundos y estar diseñados para gestionar eventos duplicados de forma idempotente.
✓Los casos de uso clave abarcan la hostelería (enriquecimiento de CRM en tiempo real), el comercio minorista (análisis omnicanal) y los eventos (datos de afluencia verificados para patrocinadores).
✓La API permite a las organizaciones transformar su infraestructura de WiFi de un centro de costes a un activo de datos estratégico con un ROI claro y medible.

Resumen Ejecutivo

Para los responsables de TI en espacios con múltiples sedes (hoteles, cadenas de retail, estadios y centros de conferencias), la red WiFi para invitados es más que un simple servicio de cortesía. Es una fuente rica y en constante renovación de datos de primera mano que puede impulsar un impacto empresarial medible en marketing, operaciones y experiencia del cliente. La API de Purple Portal proporciona la interfaz programática necesaria para desbloquear este valor a escala. Permite a los equipos técnicos ir más allá de los paneles de análisis integrados y crear integraciones sólidas y automatizadas que introducen datos de visitantes conformes con el GDPR directamente en los sistemas empresariales principales, desde plataformas CRM y herramientas de automatización de marketing hasta programas de fidelización y almacenes de inteligencia empresarial.

Esta guía es una referencia práctica y aplicable para arquitectos de soluciones, responsables de TI y desarrolladores sénior. Detalla el modelo de autenticación, los endpoints disponibles, los patrones de integración y los escenarios de despliegue reales que demuestran cómo la API de Purple WiFi puede transformar un despliegue de WiFi de un centro de costes a un activo de datos estratégico. Tanto si está evaluando la API por primera vez como si está planificando una integración a nivel de producción, este documento le proporciona la base técnica y los marcos de decisión que necesita para proceder con total confianza.

Análisis Técnico Detallado

Autenticación y Versiones de la API

La API de Purple Portal utiliza la autenticación mediante API Key, un modelo sencillo y seguro muy adecuado para integraciones de servidor a servidor. A diferencia de los flujos de OAuth 2.0, que requieren intercambio de tokens y ciclos de actualización, la autenticación mediante API Key consiste en incluir un secreto estático en las cabeceras de la solicitud. Esta simplicidad reduce la complejidad de la integración sin comprometer la seguridad, siempre que la clave se almacene de forma segura y se rote periódicamente como parte de su política estándar de gestión de credenciales.

La versión de producción actual es la v1.7, que introdujo varias mejoras importantes con respecto a la v1.6.2. Lo más significativo es que la propiedad unsubscribed en el objeto de datos del usuario ahora distingue claramente entre un usuario que canceló activamente su suscripción de marketing después de haber estado suscrito previamente, y un usuario que nunca se suscribió. Esta distinción es fundamental para el cumplimiento del GDPR y para una segmentación precisa de la audiencia. Además, los endpoints de Visitors y Venues ahora devuelven una respuesta HTTP 200 OK cuando no se encuentran datos, en lugar de un 404 Not Found, lo que anteriormente causaba confusión en la lógica de monitorización y gestión de errores.

Endpoints Disponibles

La API de Portal Company expone tres categorías principales de endpoints con las que los equipos de TI interactuarán habitualmente.

Endpoint	Método	Propósito
`/visitors`	GET	Recuperar perfiles de visitantes invitados, incluidos datos de contacto, demografía e historial de visitas
`/venues`	GET	Recuperar datos a nivel de sede y metadatos de configuración
`/unsubscribes`	GET	Recupera una lista de usuarios que han optado por no recibir comunicaciones de marketing

Todos los endpoints devuelven datos en formato JSON. El endpoint visitors es el más utilizado, ya que expone toda la riqueza de los datos del perfil del invitado recopilados durante el proceso de autenticación en el Captive Portal. Esto incluye nombre, apellidos, dirección de correo electrónico, género, fecha de nacimiento, número de teléfono móvil, código postal, proveedor de autenticación (por ejemplo, formulario de registro, inicio de sesión social), recuento de visitas por establecimiento y cualquier campo personalizado configurado en la página de inicio (splash page).

Límites de Tarifa (Rate Limits)

Una ventaja arquitectónica clave de la API de Purple Portal es que no hay límites de tarifa. La plataforma está diseñada para soportar cualquier volumen de solicitudes o transacciones, lo que la hace adecuada para despliegues a gran escala donde los scripts pueden necesitar procesar miles de registros de establecimientos o millones de perfiles de visitantes. Esto elimina una restricción común que complica el diseño de la integración con otras plataformas y evita la necesidad de limitar las solicitudes o implementar una lógica de espera (back-off) en el código de su cliente.

Patrones de Integración: Pull vs. Push

La API de Purple WiFi admite dos patrones de integración fundamentalmente diferentes, cada uno adecuado para distintos casos de uso. Comprender qué patrón aplicar en un escenario determinado es la decisión arquitectónica más importante que deberá tomar.

El patrón pull de la API REST implica que su sistema realice solicitudes bajo demanda o programadas a los endpoints de la API para recuperar datos. Este es el enfoque correcto para el procesamiento por lotes, la generación de informes y la inteligencia empresarial. Un script ETL nocturno que extrae todos los datos de los visitantes del día anterior y los carga en un almacén de datos es un ejemplo canónico. El patrón pull le brinda un control total sobre cuándo y cuántos datos recupera.

El patrón push de Webhook implica que Purple envía datos a su sistema en el momento en que ocurre un evento específico; concretamente, cuando un invitado se autentica en la red WiFi. Su sistema debe exponer un endpoint HTTP accesible públicamente y protegido por SSL (un 'listener') que pueda recibir y procesar estas cargas útiles JSON POST. El patrón Webhook es la opción correcta para cualquier caso de uso que requiera datos casi en tiempo real, como activar un mensaje de bienvenida personalizado, actualizar el estado de 'última visita' de un cliente en un CRM o notificar a un gerente de hostelería que ha llegado un invitado VIP.

Estructura de la Carga Útil (Payload) del Webhook

La carga útil JSON entregada por un Webhook de Purple se estructura en cuatro objetos principales, cada uno de los cuales proporciona una dimensión diferente de contexto para el evento de autenticación.

Objeto	Campos Clave	Descripción
`client`	`mac`, `userAgent`	Identificadores a nivel de dispositivo
`company`	`id`, `name`, `uniqId`	Detalles de la cuenta de su empresa
`venue`	`id`, `name`, `latitude`, `longitude`	La ubicación específica donde ocurrió la autenticación
`session`	`authenticationTime`	Marca de tiempo ISO 8601 del evento de autenticación
`user`	`email`, `firstName`, `lastName`, `gender`, `provider`, `visitCountForVenues`, `customFields`	Datos completos del perfil del invitado

El objeto user.visitCountForVenues es especialmente valioso para operadores de múltiples sedes. Proporciona un recuento de visitas por sede junto con las marcas de tiempo de firstVisit y lastVisit, lo que le permite identificar a los visitantes primerizos frente a los clientes recurrentes fidelizados en el momento de la autenticación, sin necesidad de realizar llamadas API adicionales.

Guía de implementación

Requisitos previos y configuración

El acceso a la API del portal requiere una licencia Engage. Una vez que disponga de la licencia, genere su clave API desde la configuración del portal de Purple. Para el desarrollo y las pruebas iniciales, Postman es la herramienta recomendada; Purple proporciona una guía de configuración dedicada para configurar las variables de entorno y las cabeceras de solicitud correctas. También hay disponible un archivo de demostración en PHP para los equipos que prefieran un punto de partida con scripts del lado del servidor.

Configuración de una integración de Webhook

La implementación de una integración de Webhook consta de cinco pasos. En primer lugar, cree e implemente su endpoint receptor en una URL accesible públicamente y protegida por SSL. Una función serverless (AWS Lambda, Azure Functions o Google Cloud Functions) es una opción arquitectónicamente sólida: se escala automáticamente, incurre en costes mínimos con volúmenes bajos y gestiona solicitudes simultáneas sin necesidad de configuración. En segundo lugar, valide la URL del receptor en el portal de Purple accediendo a Gestión > Sedes > Webhooks. Purple enviará una solicitud de prueba para confirmar que el endpoint es accesible y devuelve la cabecera wifiWebhookListener: 1 requerida. En tercer lugar, cree o edite un LogicFlow en el portal y añada un nodo de acción Webhook, seleccionando su URL validada. En cuarto lugar, asegúrese de que el LogicFlow esté en estado "Online". En quinto lugar, asocie el LogicFlow al Access Journey correspondiente. A partir de este momento, cada autenticación de invitado en ese journey activará su Webhook.

Gestión de reintentos e idempotencia

Su receptor debe estar diseñado para hacer frente a las realidades de los sistemas distribuidos. Purple reintentará el envío de un Webhook fallido transcurridas tres horas si su receptor no responde (el tiempo de espera supera los 10 segundos) o devuelve un estado de error. Esto significa que su receptor puede recibir el mismo evento varias veces. Además, una única visita de un invitado puede desencadenar múltiples eventos de autenticación; por ejemplo, cuando un dispositivo se vuelve a conectar después de que se bloquee la pantalla, o cuando un usuario realiza roaming entre puntos de acceso. Por lo tanto, su lógica de procesamiento debe ser idempotente: aplicar el mismo evento dos veces debe producir el mismo resultado que aplicarlo una sola vez. Un patrón de implementación común consiste en comprobar si ya se ha realizado una acción (como enviar un correo electrónico de bienvenida) para un ID de usuario determinado dentro de un intervalo de tiempo definido antes de ejecutarla.

Buenas prácticas

Varios principios deben guiar cualquier despliegue en producción de la Purple Portal API. Despliegue siempre con la última versión de la API (v1.7) y actualice las rutas de sus URL y la lógica de análisis de respuestas cuando se publiquen nuevas versiones. Trate su API Key como una credencial confidencial: almacénela en un gestor de secretos (como AWS Secrets Manager o Azure Key Vault) en lugar de en el código fuente o en variables de entorno en sistemas compartidos. Para los receptores de Webhooks, implemente un registro estructurado de cada carga útil entrante y respuesta para facilitar la depuración y las pistas de auditoría. Respete los campos unsubscribed y unsubscribedDate en el objeto de usuario; procesar acciones de marketing dirigidas a usuarios que han optado por no recibirlas constituye una infracción del GDPR. Por último, pruebe su integración frente a toda la gama de casos extremos: usuarios sin dirección de correo electrónico, usuarios con campos personalizados nulos y eventos de autenticación que llegan fuera de orden cronológico.

Resolución de problemas y mitigación de riesgos

El modo de fallo más común en una integración de Webhooks es un receptor lento o no disponible. Si el punto de conexión no responde de forma constante en un plazo de 10 segundos, Purple desactivará automáticamente el Webhook tras un periodo prolongado de inactividad, lo que requerirá una verificación manual en el portal. Para mitigar este riesgo, implemente un punto de conexión de comprobación de estado (health check) en el mismo servidor que su receptor e inclúyalo en la monitorización de su infraestructura. Asegúrese de que su receptor realice solo un procesamiento síncrono mínimo antes de devolver una respuesta 200 OK; derive cualquier cálculo pesado o llamada a API secundarias a una cola asíncrona.

Para las integraciones de la API REST, el riesgo principal es la obsolescencia de los datos en los sistemas secundarios si el trabajo de extracción programado falla de forma silenciosa. Implemente alertas en sus scripts ETL para notificar al equipo de operaciones si una ejecución falla o no produce resultados de forma inesperada. Al migrar de la API v1.6.2 a la v1.7, audite todo el código que haga referencia al campo unsubscribed y al punto de conexión Unsubscribes, ya que el nombre de la propiedad se corrigió de unsubcribers a unsubscribers en la v1.7.

ROI e impacto empresarial

El caso de negocio para integrarse con la API de Purple Portal está plenamente consolidado en múltiples sectores. En el sector de la hostelería, los hoteles que utilizan integraciones de CRM activadas por Webhooks informan de mejoras significativas en las tasas de apertura de correos electrónicos para comunicaciones personalizadas en comparación con las campañas de difusión genéricas, ya que el mensaje se entrega en el momento de máxima relevancia: cuando el huésped se encuentra físicamente en el establecimiento. En el sector minorista, conectar los datos de WiFi de invitados a un programa de fidelización permite a los operadores identificar y recompensar a los visitantes de alta frecuencia, aumentando el gasto medio y las tasas de visitas repetidas. Para grandes recintos públicos y centros de conferencias, las analíticas basadas en la API proporcionan los datos detallados de afluencia necesarios para justificar las valoraciones de patrocinio y optimizar la ubicación de las concesiones.

La ausencia de límites de velocidad en la API de Purple WiFi significa que el coste de la integración escala con su infraestructura, no con el volumen de datos que procesa. Para una cadena minorista nacional que procesa cientos de miles de autenticaciones diarias, esto representa una ventaja material frente a las plataformas que cobran por llamada a la API o imponen límites de rendimiento. Por lo tanto, el coste total de propiedad de una integración de la API de Purple bien estructurada consiste principalmente en el coste de desarrollo único y el coste de infraestructura continuo del receptor, ambos recuperados habitualmente dentro del primer trimestre únicamente a través de la mejora en las tasas de conversión de marketing.

Casos de éxito

Caso de éxito 1: Hostelería — Whitbread Group

Whitbread, la mayor empresa de hoteles y restaurantes del Reino Unido, opera miles de puntos de acceso WiFi para invitados en toda su red de Premier Inn y restaurantes. Al integrar la API de Purple Portal con su plataforma de CRM, el grupo pudo crear un perfil de invitado unificado que combinaba los datos de reservas online con el comportamiento de visita física registrado en el Captive Portal de WiFi. La integración de Webhooks se activa con cada autenticación de invitado, enriqueciendo el registro del CRM con la marca de tiempo de la última visita, la ubicación del establecimiento y la información del dispositivo. Esto permite al equipo de marketing segmentar las audiencias por antigüedad, frecuencia y ubicación, así como activar campañas de reactivación altamente personalizadas. El resultado técnico clave fue la reducción del tiempo transcurrido entre la llegada de un invitado y su entrada en un flujo de marketing activo, pasando de 24 horas (bajo el modelo anterior de sondeo por lotes) a menos de 60 segundos.

Caso de éxito 2: Sector minorista — Distribuidor de moda multitienda

Un minorista nacional de moda con más de 80 tiendas implementó la API de Purple Portal para resolver una brecha crítica en su estrategia de datos de clientes: disponían de datos sólidos de comercio electrónico, pero prácticamente no tenían información sobre el comportamiento de los visitantes en las tiendas físicas. Al conectar la API de WiFi para invitados de Purple a su almacén de datos existente mediante un proceso ETL nocturno, crearon por primera vez una visión omnicanal del cliente. Se consultaba el endpoint /visitors de cada tienda todas las noches y los datos se unían con los registros de transacciones de comercio electrónico utilizando la dirección de correo electrónico como clave común. En un plazo de tres meses, el equipo de analítica identificó que los clientes que se conectaban al WiFi de la tienda tenían un valor medio de pedido un 34 % superior en su siguiente compra online, lo que proporcionó un caso de negocio convincente para realizar más inversiones en la experiencia digital en tienda. La integración no requirió cambios en la infraestructura de comercio electrónico existente, lo que demostró la naturaleza de baja fricción del patrón de extracción de la API REST.

Caso de estudio 3: Eventos — Centro de conferencias

Un importante centro de conferencias del Reino Unido utilizó la API de Purple Portal para proporcionar por primera vez a los patrocinadores datos verificados de afluencia. Anteriormente, los informes de los patrocinadores dependían de recuentos manuales y escaneos de acreditaciones, métodos que requerían mucha mano de obra y eran imprecisos. Al exponer a través de la API recuentos de visitantes agregados y anonimizados por zona (asociados a los ID de los recintos en la plataforma Purple), el equipo de eventos pudo ofrecer a los patrocinadores paneles de control en tiempo real que mostraban el tiempo de permanencia y el volumen de visitantes en las áreas patrocinadas. Los datos se extraían a través de la API REST cada 15 minutos durante los eventos y se mostraban en un portal de patrocinadores personalizado. Esta capacidad contribuyó directamente a un aumento del 22 % en las tasas de renovación de patrocinios en el primer año, ya que los patrocinadores ahora podían cuantificar el alcance de sus activaciones con datos verificados de origen directo.

Definiciones clave

Webhook

Un mecanismo automatizado mediante el cual un servidor envía una notificación de datos en tiempo real (un push) a otra aplicación cuando ocurre un evento específico, a través de una solicitud HTTP POST.

En el contexto de Purple, un Webhook envía una carga útil JSON con datos del visitante a su sistema en el momento en que un invitado se autentica en la red WiFi. Esto es fundamental para las actualizaciones de CRM y marketing en tiempo real.

REST API

Un estilo arquitectónico estandarizado para crear servicios web que permite a un sistema solicitar (o extraer) datos de otro utilizando métodos HTTP estándar como GET y POST.

Los equipos de TI utilizan la REST API de Purple para escribir scripts que extraen datos masivos de visitantes y ubicaciones para su análisis en herramientas de inteligencia empresarial como Power BI o Tableau.

API Key Authentication

Un modelo de seguridad en el que se concede acceso a una API al proporcionar un token secreto único (la clave) con cada solicitud, normalmente en el encabezado de autorización HTTP.

Esto es más sencillo que OAuth e ideal para integraciones de servidor a servidor. Sus scripts deben incluir la API Key válida en los encabezados de la solicitud para acceder a los datos de Purple.

Idempotency

Una propiedad de una operación que significa que se puede aplicar varias veces sin cambiar el resultado más allá de la aplicación inicial.

Su receptor de Webhook debe ser idempotente. Si recibe el mismo evento de autenticación dos veces (lo que puede ocurrir debido a reintentos o reconexiones de dispositivos), no debería, por ejemplo, enviar dos correos electrónicos de bienvenida.

JSON (JavaScript Object Notation)

Un formato ligero y basado en texto para el intercambio de datos que es fácil de leer para los humanos y de analizar y generar para las máquinas.

La API de Purple y los Webhooks entregan todos los datos en formato JSON. Su aplicación deberá analizar este JSON para extraer campos como el correo electrónico, el nombre y el recuento de visitas.

LogicFlow

La herramienta visual de arrastrar y soltar de Purple para crear flujos de trabajo automatizados de marketing e interacción que pueden activar acciones basadas en el comportamiento y la demografía de los visitantes.

Utiliza LogicFlow para definir el recorrido del invitado. Es donde vincula su Webhook, indicando al sistema que lo active cuando un usuario alcance el estado "En línea" de su recorrido de acceso.

Captive Portal

La página web que un usuario ve y con la que debe interactuar antes de que se le conceda acceso a una red WiFi pública, que normalmente requiere autenticación o captura de datos.

La plataforma Purple impulsa el Captive Portal, y los datos introducidos por el usuario en esta página (por ejemplo, nombre, correo electrónico, campos personalizados) son los que pasan a estar disponibles a través de la Portal API.

GDPR (General Data Protection Regulation)

Una ley integral de privacidad de datos en la Unión Europea que regula la recopilación, el procesamiento y el almacenamiento de datos personales de los residentes de la UE.

La API de Purple proporciona las herramientas para crear integraciones que cumplan con el GDPR, como respetar el estado de suscripción cancelada de un usuario y permitir la exportación de datos para solicitudes de acceso de los interesados. La actualización de la API v1.7 mejoró específicamente la claridad del campo de suscripción cancelada para respaldar el cumplimiento normativo.

ETL (Extract, Transform, Load)

Un proceso de integración de datos que implica extraer datos de un sistema de origen, transformarlos al formato requerido y cargarlos en un sistema de destino, como un almacén de datos.

El patrón de extracción de la REST API se implementa normalmente como un proceso ETL, donde los datos se extraen del endpoint /visitors de Purple, se transforman para que coincidan con el esquema de destino y se cargan en un CRM o almacén de datos.

Ejemplos prácticos

Un hotel de 200 habitaciones quiere añadir automáticamente a los nuevos usuarios de WiFi de invitados a su journey de Salesforce Marketing Cloud y enviarles un correo electrónico de bienvenida.

En el Purple Portal, valide una nueva URL de Webhook que apunte a un endpoint seguro (por ejemplo, una función serverless en AWS Lambda). 2. Cree un LogicFlow "Online" que incluya el nodo Webhook, configurado para usar la URL validada. 3. Asigne este LogicFlow al journey de acceso WiFi de invitados del hotel. 4. La función serverless recibe el payload JSON tras la autenticación del invitado, extrae el correo electrónico y el nombre del usuario, y realiza una llamada API a Salesforce Marketing Cloud para añadir al usuario al journey "New Guest". 5. La función devuelve una respuesta 200 OK a Purple dentro del plazo de tiempo de espera de 10 segundos.

Comentario del examinador: Esta solución utiliza correctamente el patrón de Webhook en tiempo real, que es ideal para acciones inmediatas como el envío de un correo electrónico de bienvenida. El uso de una función serverless es una forma rentable y escalable de alojar el endpoint del receptor. Una alternativa sería realizar peticiones periódicas (polling) al endpoint de la API /visitors, pero esto introduciría un retraso de hasta 24 horas y sería significativamente menos eficiente para un requisito en tiempo real.

Una cadena de retail con 50 tiendas quiere crear un panel centralizado en Power BI para analizar las tendencias de los visitantes en todas las ubicaciones.

Cree un script (por ejemplo, en Python) que se ejecute de forma programada cada noche. 2. El script se autentica en la Purple Portal API utilizando la clave API de la empresa. 3. Realiza una iteración a través de cada uno de los 50 ID de las sedes, haciendo una llamada al endpoint /visitors para cada una de ellas para recuperar todos los datos de los visitantes del día anterior. 4. El script transforma y carga estos datos en un almacén de datos centralizado (por ejemplo, Azure SQL o BigQuery). 5. Power BI se conecta al almacén de datos para crear el panel de análisis de todas las sedes.

Comentario del examinador: Este es un proceso ETL (Extract, Transform, Load) clásico y es el uso correcto del patrón de consulta (polling) de la REST API. Es adecuado para la agregación de datos a gran escala que no requiere tiempo real para la inteligencia empresarial. El uso de un almacén de datos centralizado es una práctica recomendada para el rendimiento y la escalabilidad cuando se manejan datos de múltiples fuentes. La ausencia de límites de velocidad (rate limits) en la API de Purple significa que el script puede procesar las 50 sedes sin preocuparse por la limitación de solicitudes.

Preguntas de práctica

Q1. Un estadio quiere identificar a los abonados VIP de la temporada cuando se conectan al WiFi y enviar una notificación al panel del gestor de hospitalidad más cercano. ¿Qué patrón de integración deberían utilizar y por qué?

Sugerencia: Considera la velocidad requerida para la notificación y si la acción se activa mediante un evento.

Ver respuesta modelo

Deberían utilizar el patrón de Webhook (push). Se trata de un requisito en tiempo real: cuando el VIP se conecta, un Webhook se activa inmediatamente hacia un servicio que busca el correo electrónico o la dirección MAC del usuario en la base de datos de abonados de la temporada. Si se encuentra una coincidencia, envía una notificación al panel de hospitalidad correspondiente. Un patrón de REST API (pull) sería demasiado lento, ya que depende de consultas periódicas y podría introducir retrasos de minutos u horas.

Q2. Tienes la tarea de crear un informe diario de los 10 locales más visitados en tu cadena nacional de cafeterías. ¿Cómo recuperarías los datos necesarios de Purple?

Sugerencia: ¿Se trata de un requisito de informes por lotes o en tiempo real? ¿A qué endpoint realizarías la consulta?

Ver respuesta modelo

Esta es una tarea de informes por lotes, por lo que el patrón de REST API (pull) es el adecuado. Un script programado se ejecutaría diariamente, consultaría el endpoint /visitors para cada local, agregaría los recuentos de visitas del día anterior y luego calcularía los 10 principales. No es necesaria la notificación casi instantánea que proporcionan los Webhooks. La ausencia de límites de velocidad (rate limits) significa que se pueden consultar todos los locales en una sola ejecución del script sin preocuparse por la regulación de tráfico.

Q3. El endpoint de tu receptor de Webhook está fallando. Revisas los registros y ves un error de tiempo de espera (timeout). ¿Cuál es la causa más probable según la documentación de Purple y cuáles son las dos consecuencias inmediatas?

Sugerencia: Piensa en los requisitos de rendimiento de un receptor (listener) y en lo que hace Purple cuando no puede entregar una carga útil (payload).

Ver respuesta modelo

La causa más probable es que el receptor esté tardando más de 10 segundos en procesar la carga útil JSON entrante y devolver una respuesta 200 OK. Las dos consecuencias inmediatas son: (1) Purple dejará de intentar enviar la solicitud actual y la volverá a poner en cola para un intento de reintento en 3 horas, lo que significa que la entrega de datos se retrasa; y (2) si esto continúa durante un período prolongado, Purple desactivará automáticamente el Webhook por completo, lo que requerirá una verificación manual en el portal antes de que pueda volver a activarse.

Continúe leyendo esta serie

Integración de CommScope Ruckus con Purple WiFi: Guía de instalación y configuración

Esta guía de referencia técnica proporciona un manual de configuración definitivo para integrar arquitecturas de CommScope Ruckus con Purple WiFi. Detalla implementaciones paso a paso para captive portals de Guest WiFi, WiFi seguro para el personal a través de 802.1X y aislamiento de red multiinquilino mediante Ruckus Dynamic PSK.

Integración de puntos de acceso Allied Telesis con Purple WiFi

Esta guía proporciona un manual de configuración completo para integrar los puntos de acceso de la serie TQ de Allied Telesis con Purple WiFi. Cubre la redirección externa de Captive Portal, la autenticación RADIUS 802.1X y el direccionamiento dinámico de VLAN mediante claves precompartidas privadas (PPSK) para despliegues multiinquilino seguros.

Integración de los puntos de acceso Grandstream GWN con Purple WiFi

Esta guía técnica de referencia autorizada detalla cómo integrar los puntos de acceso Grandstream GWN con la plataforma de análisis y Guest WiFi de Purple. Cubre la configuración del Captive Portal de Grandstream, los ajustes de RADIUS AAA, la configuración de walled garden, la autenticación segura para el personal mediante 802.1X con direccionamiento dinámico de VLAN y la segmentación PPSK multiinquilino, proporcionando una guía práctica paso a paso para MSP e instalaciones de TI que desplieguen WiFi para invitados y personal a gran escala.