Purple Portal API: What You Can Do With It

Una referencia técnica para gerentes 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 del mundo real para integrar datos de WiFi de invitados con sistemas empresariales para mejorar la inteligencia de negocios y la eficiencia operativa. Cubre patrones de integración tanto de REST API como de Webhooks, con casos de estudio concretos de los sectores de hospitalidad, retail y eventos.

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

Escucha esta guía

Ver transcripción del podcast

Bienvenido al Informe Técnico de Purple. Soy Senior Content Strategist 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 comercial. Esto está dirigido a los gerentes de TI, los arquitectos y los 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. Usted ofrece WiFi para invitados en sus establecimientos. Todos los días, cientos o miles de personas se conectan. Proporcionan su correo electrónico, tal vez su nombre, y aceptan sus términos. Esos son valiosos datos de primera mano. El portal de Purple le ofrece excelentes tableros para visualizar esto, pero el verdadero poder surge cuando conecta esos datos con el resto de su ecosistema empresarial. Ahí es donde entra la Portal API. Es el puente que permite a sus sistemas comunicarse con nuestra plataforma de manera programática.

Ahora, entremos en los detalles técnicos. La Portal API es una interfaz RESTful estándar. La autenticación es simple y segura, utilizando 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 hay límites de velocidad. La diseñamos para una escala empresarial, por lo que, ya sea que gestione un solo hotel o una cadena nacional de quinientas tiendas minoristas, la API puede manejar su volumen.

Tiene dos formas principales de extraer datos. Primero, el método de extracción (pull): endpoints REST estándar. Piense en endpoints como visitantes y establecimientos. Puede escribir un script para llamar a estos endpoints de forma programada, 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 su opción ideal para la inteligencia empresarial, para crear esos tableros de visión general en Power BI o Tableau.

Pero la parte realmente emocionante es el método de inserción (push): Webhooks. Esto es para tiempo real. Usted configura un endpoint de escucha de 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 utilizó, ya sea un formulario de registro, inicio de sesión social u otro. Es casi instantáneo. Esto es lo que habilita una interacción inmediata y personalizada. Es la diferencia entre enviar un correo electrónico de marketing mañana y enviar una notificación de bienvenida con una oferta única en el segundo en que un cliente leal cruza su puerta.

Permítame hablar sobre 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 brindan los identificadores y las coordenadas geográficas de la ubicación específica. El objeto session le da la marca de tiempo de autenticación. Y el objeto user es donde está lo más valioso: nombre, apellido, correo electrónico, género, fecha de nacimiento, número de teléfono móvil, código postal y un recuento de visitas por venue que muestra las fechas de la primera y última visita. También puede capturar campos personalizados del formulario de registro de su splash page, por lo que si solicita a los huéspedes su número de programa de lealtad o su número de habitación en un hotel, eso también se incluye.

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, frente a aquellos que simplemente nunca optaron por participar. Esto es fundamental para el cumplimiento de 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 de acceso público 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 maneja la concurrencia que vería en un venue concurrido. 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 verificación de lealtad) 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 dentro de diez segundos. Si no lo hace, Purple volverá a poner en cola la solicitud y lo reintentará después de tres horas. Las fallas persistentes harán que el Webhook se deshabilite automáticamente por razones 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 hacer esto concreto.

Consideremos un hotel de doscientas habitaciones. Quieren registrar automáticamente a los nuevos huéspedes de WiFi en un flujo de correos 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, verificar si ya existe en la plataforma de marketing. Si no es así, agregarlo y activar el flujo de bienvenida. El hotel también puede utilizar el campo de recuento de visitas para distinguir a los visitantes primerizos de los huéspedes recurrentes y adaptar la comunicación en consecuencia. Un huésped recurrente podría recibir una oferta de recompensa por lealtad en lugar de una bienvenida genérica.

Ahora consideremos una cadena de tiendas minoristas nacional con cincuenta sucursales. Quieren un panel centralizado que muestre las tendencias de tráfico de personas en todas las ubicaciones. Aquí, el patrón de extracción de la REST API es la opción correcta. Un script nocturno consulta el endpoint de visitantes para cada una de las cincuenta sedes, agrega los datos y los carga en un almacén de datos. Luego, el equipo de analítica crea sus paneles sobre esta base. Pueden ver qué tiendas tienen las tasas más altas de visitantes nuevos, cuáles tienen los mejores índices de visitantes recurrentes y cómo se correlacionan los tiempos de permanencia con el rendimiento de las ventas.

Permítanme ahora cubrir algunos errores comunes y cómo evitarlos.

El primer error es la gestión de eventos duplicados. Una sola visita de un 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 hace roaming entre puntos de acceso. Su receptor debe ser idempotente. Antes de realizar una acción como enviar un correo electrónico, verifique si ya procesó un evento para ese usuario el día de hoy.

El segundo error es no validar la URL de su receptor antes de entrar en producción. 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 el encabezado wifiWebhookListener correcto antes de asociarlo a un LogicFlow.

El tercer error es ignorar el estado de suscripción. Siempre verifique el campo de dados de baja antes de agregar a un usuario a una lista de marketing. Enviar comunicaciones de marketing a alguien que ha optado por no recibirlas es una infracción de GDPR con consecuencias significativas.

Ahora, pasemos a una sesión rápida de preguntas y respuestas.

¿Puedo sincronizar esto con mi CRM personalizado? Sí. Si su CRM tiene una API, puede usar un receptor de Webhook como middleware para dar formato a los datos de Purple y enviarlos a su sistema. Los ID devueltos en el payload 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 varias sucursales en mi propiedad? La API proporciona recuentos de visitas por ID de sede, por lo que puede rastrear fácilmente el recorrido de un cliente a través de toda su propiedad y crear un perfil completo de múltiples sitios.

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

¿Qué pasa si mi receptor se cae por mantenimiento? Purple reintentará las entregas fallidas, por lo que podría recibir una acumulación de eventos pendientes cuando su receptor vuelva a estar en línea. Su receptor debe manejar esto de manera fluida, procesando los eventos que puedan llegar fuera de orden cronológico.

Para resumir todo lo que hemos cubierto hoy, la API del Purple Portal es su clave para desbloquear el inmenso valor de los datos de su WiFi de invitados. Utilice la API REST para extraer datos para informes y analíticas. Utilice Webhooks para enviar datos en tiempo real para una interacción con el cliente inmediata y personalizada. Recuerde el principio clave: enviar para tiempo real, extraer para informes.

Su siguiente paso es revisar la documentación de la API en nuestro portal de soporte. Si tiene una licencia de Engage, genere una clave de API y comience a explorar con Postman. Construya un receptor de Webhook sencillo. Vea cómo fluyen los datos. Ese es el momento en que el potencial de esta herramienta se vuelve completamente claro.

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.

Puntos clave

✓La API de Purple Portal proporciona acceso programático a los datos de WiFi de invitados mediante una autenticación sencilla con API Key, sin límites de velocidad.
✓Requiere una licencia Engage y actualmente opera en la versión v1.7, la cual mejoró el cumplimiento de GDPR mediante un manejo más claro del estado de suscripción cancelada.
✓Utiliza la REST API (pull) para exportaciones de datos por lotes, procesos ETL y paneles de analítica.
✓Utiliza Webhooks (push) para acciones en tiempo real basadas en eventos, como sincronizaciones de CRM, mensajería personalizada y activadores de lealtad.
✓Los receptores de Webhooks deben estar protegidos con SSL, responder en un plazo de 10 segundos y estar diseñados para manejar eventos duplicados de forma idempotente.
✓Los casos de uso clave abarcan la hospitalidad (enriquecimiento de CRM en tiempo real), el comercio minorista (analítica 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 costos a un activo de datos estratégico con un ROI claro y medible.

Resumen Ejecutivo

Para los líderes de TI en establecimientos multisitio (hoteles, cadenas de retail, estadios y centros de convenciones), la red WiFi para invitados es más que un simple servicio. Es una fuente rica y en constante actualización de datos de primera mano que puede impulsar un impacto comercial medible en marketing, operaciones y experiencia del cliente. La Purple Portal API proporciona la interfaz programática necesaria para liberar este valor a escala. Permite a los equipos técnicos ir más allá de los paneles de analítica integrados y crear integraciones sólidas y automatizadas que alimentan los sistemas empresariales principales directamente con datos de visitantes que cumplen con el GDPR, desde plataformas de CRM y herramientas de automatización de marketing hasta programas de lealtad y almacenes de inteligencia empresarial.

Esta guía es una referencia práctica y aplicable para arquitectos de soluciones, gerentes de TI y desarrolladores senior. Detalla el modelo de autenticación, los endpoints disponibles, los patrones de integración y los escenarios de implementación del mundo real que demuestran cómo la Purple WiFi API puede transformar una implementación de WiFi de un centro de costos a un activo de datos estratégico. Ya sea que esté evaluando la API por primera vez o planificando una integración de nivel de producción, este documento proporciona los fundamentos técnicos y los marcos de decisión que necesita para proceder con confianza.

Análisis Técnico Detallado

Autenticación y Versiones de la API

La Purple Portal API utiliza la autenticación por API Key, un modelo sencillo y seguro que se adapta perfectamente a las integraciones de servidor a servidor. A diferencia de los flujos de OAuth 2.0, que requieren ciclos de intercambio y renovación de tokens, la autenticación por API Key consiste en incluir un secreto estático en los encabezados 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, la cual introdujo varias mejoras importantes con respecto a la v1.6.2. De manera muy significativa, 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 de audiencia precisa. 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 monitoreo y manejo de errores.

Endpoints Disponibles

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

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 establecimiento 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 huésped recopilados durante el proceso de autenticación del Captive Portal. Esto incluye nombre, apellido, 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 sucursal y cualquier campo personalizado configurado en la splash page.

Límites de tasa (Rate Limits)

Una ventaja arquitectónica clave de la API de Purple Portal es que no hay límites de tasa. La plataforma está diseñada para soportar cualquier volumen de solicitudes o transacciones, lo que la hace adecuada para implementaciones a gran escala donde los scripts pueden necesitar procesar miles de registros de sucursales o millones de perfiles de visitantes. Esto elimina una restricción común que complica el diseño de integración con otras plataformas y elimina la necesidad de limitar las solicitudes o aplicar lógica de espera (back-off) en su código de 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 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, informes e inteligencia de negocios. 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 control total sobre cuándo y cuántos datos recupera.

El patrón push de Webhook implica que Purple envíe datos a su sistema en el momento en que ocurre un evento específico; concretamente, cuando un huésped 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 estos payloads 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 vez visto" de un cliente en un CRM o notificar a un gerente de hospitalidad que ha llegado un huésped VIP.

Estructura de payload de Webhook

El payload JSON entregado por un Webhook de Purple está estructurado 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 los operadores de múltiples sitios. Proporciona un recuento de visitas por sucursal junto con las marcas de tiempo firstVisit y lastVisit, lo que le permite identificar a los visitantes primerizos frente a los clientes recurrentes leales en el momento de la autenticación, sin necesidad de realizar llamadas de API adicionales.

Guía de Implementación

Prerrequisitos y Configuración

El acceso a la Portal API requiere una licencia Engage. Una vez que tenga la licencia, genere su API Key desde la configuración del portal de Purple. Para el desarrollo y las pruebas iniciales, se recomienda utilizar Postman; Purple proporciona una guía de configuración dedicada para configurar las variables de entorno y los encabezados de solicitud correctos. También está disponible un archivo de demostración en PHP para los equipos que prefieran un punto de partida con scripting 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. Primero, cree e implemente su endpoint receptor en una URL de acceso público 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, genera costos mínimos con volúmenes bajos y maneja solicitudes concurrentes sin necesidad de configuración. Segundo, valide la URL del receptor en el portal de Purple navegando a Management > Venues > Webhooks. Purple enviará una solicitud de prueba para confirmar que el endpoint es accesible y devuelve el encabezado wifiWebhookListener: 1 requerido. Tercero, cree o edite un LogicFlow en el portal y agregue un Webhook Action Node, seleccionando su URL validada. Cuarto, asegúrese de que el LogicFlow esté en estado "Online". Quinto, asocie el LogicFlow al Access Journey correspondiente. A partir de este momento, cada autenticación de invitado en ese journey activará su Webhook.

Manejo de Reintentos e Idempotencia

Su receptor debe estar diseñado para manejar las realidades de los sistemas distribuidos. Purple reintentará la entrega de un Webhook fallido después de 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 sola visita de un invitado puede activar múltiples eventos de autenticación; por ejemplo, cuando un dispositivo se vuelve a conectar después de que se bloquea la pantalla, o cuando un usuario se desplaza 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 verificar 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 período de tiempo definido antes de ejecutarla.

Mejores Prácticas

Several principles should guide any production deployment of the Purple Portal API. Always deploy against the latest API version (v1.7) and update your URL paths and response parsing logic when new versions are released. Treat your API Key as a sensitive credential: store it in a secrets manager (such as AWS Secrets Manager or Azure Key Vault) rather than in source code or environment variables on shared systems. For Webhook listeners, implement structured logging of every incoming payload and response to facilitate debugging and audit trails. Respect the unsubscribed and unsubscribedDate fields in the user object; processing marketing actions against opted-out users constitutes a GDPR violation. Finally, test your integration against the full range of edge cases: users with no email address, users with custom fields that are null, and authentication events that arrive out of chronological order.

Troubleshooting & Risk Mitigation

The most common failure mode in a Webhook integration is a slow or unavailable listener. If the endpoint consistently fails to respond within 10 seconds, Purple will automatically disable the Webhook after a prolonged period of unresponsiveness, requiring manual re-verification in the portal. To mitigate this risk, implement a health check endpoint on the same server as your listener and include it in your infrastructure monitoring. Ensure your listener performs only minimal synchronous processing before returning a 200 OK response; offload any heavy computation or downstream API calls to an asynchronous queue.

For REST API integrations, the primary risk is data staleness in downstream systems if the scheduled pull job fails silently. Implement alerting on your ETL scripts to notify the operations team if a run fails or produces no output unexpectedly. When migrating from API v1.6.2 to v1.7, audit all code that references the unsubscribed field and the Unsubscribes endpoint, as the property name was corrected from unsubcribers to unsubscribers in v1.7.

ROI & Business Impact

El caso de negocio para integrarse con la API de Purple Portal está bien consolidado en múltiples sectores. En el sector de la hospitalidad, los hoteles que utilizan integraciones de CRM activadas por Webhooks reportan 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, debido a 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 lealtad permite a los operadores identificar y recompensar a los visitantes de alta frecuencia, incrementando el gasto promedio y las tasas de visitas repetidas. Para grandes recintos públicos y centros de conferencias, las analíticas impulsadas por 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 costo 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 sobre las plataformas que cobran por llamada de API o imponen límites de rendimiento. Por lo tanto, el costo total de propiedad para una integración de la API de Purple bien estructurada consiste principalmente en el costo de desarrollo de una sola vez y el costo de infraestructura continuo del receptor, los cuales se recuperan típicamente dentro del primer trimestre únicamente a través de la mejora en las tasas de conversión de marketing.

Casos de Estudio

Caso de Estudio 1: Hospitalidad — Whitbread Group

Whitbread, la compañía de hoteles y restaurantes más grande del Reino Unido, opera miles de puntos de acceso WiFi para invitados en toda su propiedad de Premier Inn y restaurantes. Al integrar la API de Purple Portal con su plataforma de CRM, el grupo pudo construir un perfil de huésped unificado que combinaba los datos de reservaciones en línea con el comportamiento de visitas físicas capturado 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 nivel de actividad reciente, frecuencia y ubicación, así como activar campañas de reactivación altamente personalizadas. El resultado técnico clave fue una reducción en el tiempo entre la llegada de un huésped y su ingreso a un flujo de marketing activo, pasando de 24 horas (bajo el modelo anterior de consulta por lotes) a menos de 60 segundos.

Caso de Estudio 2: Comercio Minorista — Minorista de Moda Multisitio

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: contaban con 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 una vista de cliente omnicanal por primera vez. Se consultó el endpoint /visitors para cada tienda todas las noches, y los datos se unieron 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 de pedido promedio un 34% más alto en su siguiente compra en línea, lo que proporcionó un caso de negocio sólido para una mayor inversión 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.

Case Study 3: Events — Conference Centre

Un importante centro de conferencias en el Reino Unido utilizó la API de Purple Portal para proporcionar a los patrocinadores, por primera vez, datos verificados de afluencia de personas. Anteriormente, los informes de los patrocinadores dependían de conteos manuales y escaneos de credenciales, lo que requería mucha mano de obra y resultaba impreciso. Al exponer recuentos de visitantes agregados y anonimizados por zona (mapeados con ID de ubicaciones en la plataforma de Purple) a través de la API, el equipo de eventos pudo ofrecer a los patrocinadores tableros 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 primera mano.

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 la creación de 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 necesitará 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 y engagement que pueden activar acciones basadas en el comportamiento y la demografía de los visitantes.

Usted utiliza LogicFlow para definir el recorrido del invitado. Es donde vincula su Webhook, indicándole 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 del interesado. La actualización de la API v1.7 mejoró específicamente la claridad del campo de suscripción cancelada para respaldar el cumplimiento.

ETL (Extract, Transform, Load)

Un proceso de integración de datos que consiste en 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 resueltos

Un hotel de 200 habitaciones desea agregar automáticamente nuevos usuarios de WiFi de invitados a su journey de Salesforce Marketing Cloud y enviar 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 de WiFi de invitados del hotel. 4. La función serverless recibe el payload JSON al autenticarse el invitado, extrae el correo electrónico y el nombre del usuario, y realiza una llamada de API a Salesforce Marketing Cloud para agregar al usuario al journey 'New Guest'. 5. La función devuelve una respuesta 200 OK a Purple dentro de la ventana de tiempo de espera de 10 segundos.

Comentario del examinador: Esta solución utiliza correctamente el patrón de Webhook en tiempo real, el cual es ideal para acciones inmediatas como enviar 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 consultas 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 desea crear un tablero central en Power BI para analizar las tendencias de los visitantes en todas las ubicaciones.

Cree un script (por ejemplo, en Python) que se ejecute en un horario nocturno. 2. El script se autentica en la Purple Portal API utilizando la clave de API de la empresa. 3. Itera a través de cada uno de los 50 IDs de los establecimientos, realizando una llamada al endpoint /visitors para cada uno con el fin de 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 central (por ejemplo, Azure SQL o BigQuery). 5. Power BI se conecta al almacén de datos para crear el tablero de analítica multi-establecimiento.

Comentario del examinador: Este es un proceso clásico de ETL (Extraer, Transformar, Cargar) 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 de negocios. El uso de un almacén de datos central es una mejor práctica 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 los 50 establecimientos sin preocuparse por la regulación de tráfico (throttling).

Preguntas de práctica

Q1. Un estadio desea identificar a los abonados VIP de la temporada cuando se conectan al WiFi y enviar una notificación al panel del gerente 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 desencadena por un evento.

Ver respuesta modelo

Deberían utilizar el patrón de Webhook (push). Este es 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 reporte diario de las 10 sucursales más visitadas en tu cadena nacional de cafeterías. ¿Cómo recuperarías los datos necesarios desde Purple?

Sugerencia: ¿Es este un requisito de reporte en tiempo real o por lotes? ¿Qué endpoint consultarías?

Ver respuesta modelo

Esta es una tarea de reporte 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 sucursal, agregaría los conteos de visitas del día anterior y luego calcularía el top 10. No hay necesidad de la notificación casi instantánea que proporcionan los Webhooks. La ausencia de límites de velocidad significa que todas las sucursales se pueden consultar 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 logs 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 y en lo que hace Purple cuando no puede entregar un payload.

Ver respuesta modelo

La causa más probable es que el receptor esté tardando más de 10 segundos en procesar el payload 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 encolar para un intento de reintento en 3 horas, lo que significa que la entrega de datos se retrasará; y (2) si esto continúa durante un período prolongado, Purple desactivará automáticamente el Webhook por completo, requiriendo una verificación manual en el portal antes de poder activarlo de nuevo.

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 multi-inquilino mediante Dynamic PSK de Ruckus.

Integración de Access Points Allied Telesis con Purple WiFi

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

Grandstream GWN Access Points Integration with Purple WiFi

Esta guía de referencia técnica 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 del walled garden, la autenticación segura para el personal mediante 802.1X con direccionamiento dinámico de VLAN y la segmentación PPSK multi-tenant, proporcionando una guía paso a paso y práctica para MSPs y equipos de TI que despliegan WiFi para invitados y personal a gran escala.