API Purple Portal : Ce que vous pouvez faire avec

Une référence technique pour les responsables informatiques et les architectes réseau sur l'exploitation de l'API Purple Portal. Ce guide détaille les points de terminaison disponibles, l'authentification et les cas d'utilisation réels pour l'intégration des données du WiFi invité aux systèmes de l'entreprise afin d'améliorer la business intelligence et l'efficacité opérationnelle. Il couvre à la fois l'API REST et les modèles d'intégration de Webhooks, avec des études de cas concrètes issues des secteurs de l'hôtellerie, du commerce de détail et de l'événementiel.

📖 9 min de lecture📝 2,212 mots🔧 2 exemples concrets❓ 3 questions d'entraînement📚 9 définitions clés

Écouter ce guide

Voir la transcription du podcast

Bienvenue dans cette présentation technique de Purple. Je suis concepteur-rédacteur senior chez Purple, et au cours des dix prochaines minutes, je vais vous proposer un aperçu concis et pratique de notre Portal API : ce qu'elle est, ce que vous pouvez faire avec, et comment en tirer parti pour un impact commercial maximal. Cette présentation s'adresse aux responsables informatiques, aux architectes et aux directeurs des opérations qui ont besoin de savoir comment transformer leur WiFi invité d'un simple service utilitaire en un puissant actif de données.

Commençons par le contexte. Vous proposez un WiFi invité dans vos différents points de vente ou établissements. Chaque jour, des centaines ou des milliers de personnes s'y connectent. Elles fournissent leur adresse e-mail, parfois leur nom, et acceptent vos conditions d'utilisation. Il s'agit de données de première main précieuses. Le portail Purple vous offre d'excellents tableaux de bord pour visualiser ces données, mais leur véritable force se révèle lorsque vous les connectez au reste de votre écosystème d'entreprise. C'est là que le Portal API intervient. C'est la passerelle qui permet à vos systèmes de communiquer de manière programmatique avec notre plateforme.

Entrons maintenant dans les détails techniques. Le Portal API est une interface RESTful standard. L'authentification est simple et sécurisée, à l'aide d'une clé API classique. Vous n'avez pas à vous soucier de processus de validation OAuth complexes pour la communication de serveur à serveur. De plus, il n'y a pas de limites de taux (rate limits). Nous l'avons conçue pour s'adapter à l'échelle de l'entreprise : que vous gériez un seul hôtel ou une chaîne nationale de cinq cents magasins, l'API peut absorber votre volume de requêtes.

Vous disposez de deux méthodes principales pour extraire les données. Tout d'abord, la méthode « pull » (tirer) : les points de terminaison REST standards. Pensez à des points de terminaison tels que les visiteurs et les établissements (venues). Vous pouvez écrire un script pour appeler ces points de terminaison de manière planifiée, récupérer toutes les données des visiteurs des dernières vingt-quatre heures et les charger dans votre entrepôt de données pour analyse. C'est la solution idéale pour l'informatique décisionnelle (Business Intelligence), afin de concevoir des tableaux de bord globaux dans Power BI ou Tableau.

Mais le plus intéressant reste la méthode « push » (pousser) : les Webhooks. C'est la solution pour le temps réel. Vous configurez un point de terminaison d'écoute de votre côté, et dès qu'un invité s'authentifie sur votre WiFi, nous vous envoyons une charge utile JSON contenant toutes ses coordonnées : nom, adresse e-mail, établissement dans lequel il se trouve, nombre de visites, et même la méthode d'authentification utilisée (formulaire d'inscription, connexion via les réseaux sociaux ou autre). C'est presque instantané. C'est ce qui permet un engagement immédiat et personnalisé. C'est toute la différence entre envoyer un e-mail marketing le lendemain et envoyer une notification de bienvenue personnalisée avec une offre unique à la seconde même où un client fidèle franchit votre porte.

Permettez-moi de vous présenter les champs de données dont vous disposez. Le payload du Webhook est structuré en quatre objets principaux. L'objet client vous fournit l'adresse MAC et l'user agent. Les objets company et venue vous fournissent les identifiants et les coordonnées géographiques du lieu spécifique. L'objet session vous indique l'horodatage d'authentification. Et l'objet user recèle les données les plus précieuses : prénom, nom, e-mail, genre, date de naissance, numéro de téléphone portable, code postal, ainsi qu'un compteur de visites par lieu indiquant les dates de première et de dernière visite. Vous pouvez également capturer des champs personnalisés à partir de votre formulaire d'inscription sur la page d'accueil (splash page). Ainsi, si vous demandez aux clients leur numéro de programme de fidélité ou leur numéro de chambre d'hôtel, ces données sont également transmises.

Désormais, dans la version 1.7 de l'API, une amélioration importante est à noter. Le champ des personnes désinscrites distingue désormais clairement les utilisateurs qui se sont activement désabonnés du marketing après avoir été inscrits, de ceux qui n'ont tout simplement jamais donné leur accord. C'est un point essentiel pour la conformité au GDPR et pour une segmentation précise. Vous ne souhaitez pas traiter un abonné désengagé de la même manière qu'un utilisateur qui n'a jamais fait partie de votre entonnoir marketing.

Examinons de plus près les schémas d'intégration. Pour le modèle de pull via l'API REST, votre flux de travail standard est un script planifié, par exemple en Python ou Node.js, qui s'exécute chaque nuit. Il s'authentifie avec votre clé API, interroge l'endpoint des visiteurs pour chaque lieu, transforme les données dans le format requis et les charge dans une base de données centrale. Il s'agit d'un processus ETL classique. Pour un opérateur multi-sites, vous passeriez en revue vos identifiants de lieux et agrégerez les données de manière centralisée.

Pour le modèle de push via Webhook, l'architecture est légèrement différente. Vous devez disposer d'un endpoint accessible publiquement et sécurisé par SSL. Une fonction serverless est ici idéale : AWS Lambda, Azure Functions ou Google Cloud Functions. C'est une solution rentable, qui s'adapte automatiquement à l'échelle et gère la simultanéité que l'on observe sur un site à forte affluence. Lorsque la fonction reçoit la requête POST de Purple, elle doit analyser le JSON, exécuter sa logique métier — par exemple une recherche CRM ou une vérification de fidélité — et renvoyer une réponse 200 OK le plus rapidement possible.

Cela m'amène à l'exigence d'implémentation la plus cruciale : votre listener doit répondre dans un délai de dix secondes. Dans le cas contraire, Purple placera à nouveau la requête dans la file d'attente et fera une nouvelle tentative après trois heures. Des échecs persistants entraîneront la désactivation automatique du Webhook pour des raisons de sécurité. Veillez donc à ce que votre listener reste léger. Effectuez le traitement minimal nécessaire pour renvoyer une réponse rapide et, si vous devez effectuer des traitements lourds, poussez l'événement dans une file d'attente interne et traitez-le de manière asynchrone.

Voyons maintenant quelques scénarios concrets pour illustrer cela.

Prenons l'exemple d'un hôtel de deux cents chambres. Ils souhaitent inscrire automatiquement les nouveaux clients connectés au WiFi à un scénario d'e-mails de bienvenue dans leur plateforme marketing. La solution est simple : configurer un Webhook, créer un écouteur serverless simple et, lorsque les données d'un nouvel utilisateur arrivent, vérifier s'il existe déjà dans la plateforme marketing. Si ce n'est pas le cas, ajoutez-le et déclenchez le scénario de bienvenue. L'hôtel peut également utiliser le champ du nombre de visites pour distinguer les nouveaux visiteurs des clients réguliers et adapter la communication en conséquence. Un client régulier pourrait ainsi recevoir une offre de fidélité plutôt qu'un message de bienvenue générique.

Considérons maintenant une chaîne de vente au détail nationale de cinquante magasins. Ils souhaitent un tableau de bord centralisé affichant les tendances de fréquentation de l'ensemble de leurs points de vente. Ici, le modèle d'extraction par API REST est le choix idéal. Un script nocturne interroge le point de terminaison des visiteurs pour chacun des cinquante sites, agrège les données et les charge dans un entrepôt de données. L'équipe d'analystes conçoit ensuite ses tableaux de bord à partir de ces informations. Elle peut ainsi identifier les magasins qui enregistrent les taux de nouveaux visiteurs les plus élevés, ceux qui affichent les meilleurs ratios de clients réguliers et la manière dont le temps de séjour est corrélé aux performances des ventes.

Permettez-moi maintenant d'aborder certains pièges courants et la manière de les éviter.

Le premier piège est la gestion des événements en double. Une seule visite d'un client peut déclencher plusieurs événements d'authentification — par exemple, s'il laisse l'écran de son téléphone se verrouiller et qu'il se reconnecte, ou s'il navigue entre différents points d'accès. Votre écouteur doit être idempotent. Avant d'entreprendre une action telle que l'envoi d'un e-mail, vérifiez si vous avez déjà traité un événement pour cet utilisateur aujourd'hui.

Le deuxième piège consiste à ne pas valider l'URL de votre écouteur avant la mise en service. Purple exige que vous validiez le point de terminaison dans le portail avant de pouvoir recevoir des données. Assurez-vous que votre écouteur est actif et renvoie l'en-tête wifiWebhookListener correct avant de l'associer à un LogicFlow.

Le troisième piège est d'ignorer le statut d'abonnement. Vérifiez toujours le champ de désinscription avant d'ajouter un utilisateur à une liste marketing. L'envoi de communications marketing à une personne qui s'est désinscrite constitue une violation du GDPR avec des conséquences importantes.

Passons maintenant à une séance rapide de questions-réponses.

Puis-je synchroniser cela avec mon CRM personnalisé ? Oui. Si votre CRM dispose d'une API, vous pouvez utiliser un écouteur de Webhook comme middleware pour formater les données de Purple et les envoyer vers votre système. Les identifiants renvoyés dans la charge utile du Webhook correspondent à ceux de l'API REST, ce qui vous permet également d'effectuer des appels complémentaires pour obtenir des détails supplémentaires si nécessaire.

Comment gérer un utilisateur qui visite plusieurs sites de mon réseau ? L'API fournit le nombre de visites par identifiant de site, ce qui vous permet de suivre facilement le parcours d'un client sur l'ensemble de votre réseau et de concevoir un profil multi-sites complet.

Y a-t-il une limite au nombre d'URL de Webhooks que je peux configurer ? Non. Vous pouvez valider et utiliser autant d'URL d'écouteurs que nécessaire, ce qui est particulièrement utile si différentes équipes ou différents systèmes doivent recevoir les mêmes données d'événement.

Que se passe-t-il si mon écouteur est hors ligne pour maintenance ? Purple réessayera les envois ayant échoué, vous risquez donc de recevoir un arriéré d'événements lorsque votre écouteur sera de nouveau en ligne. Votre écouteur doit gérer cette situation de manière fluide, en traitant des événements qui peuvent arriver dans un ordre non chronologique.

Pour résumer tout ce que nous avons abordé aujourd'hui, l'API du Portail Purple est votre clé pour libérer l'immense valeur de vos données WiFi invités. Utilisez l'API REST pour extraire des données à des fins de rapports et d'analyses. Utilisez les Webhooks pour envoyer des données en temps réel pour un engagement client immédiat et personnalisé. Gardez à l'esprit le principe clé : le push pour le temps réel, le pull pour les rapports.

Votre prochaine étape consiste à consulter la documentation de l'API dans notre portail d'assistance. Si vous possédez une licence Engage, générez une clé API et commencez à explorer avec Postman. Créez un simple écouteur de Webhook. Regardez les données arriver. C'est à ce moment-precis que le potentiel de cet outil devient limpide.

Merci d'avoir écouté ce briefing technique de Purple. Si vous souhaitez vous entretenir avec l'un de nos architectes de solutions au sujet de vos besoins d'intégration spécifiques, visitez purple dot ai et réservez une démo. À la prochaine.

Points clés à retenir

✓L'API du portail Purple permet un accès programmatique aux données WiFi des invités en utilisant une simple authentification par clé API, sans limite de débit.
✓Elle nécessite une licence Engage et fonctionne actuellement sur la version v1.7, qui a amélioré la conformité au GDPR grâce à une gestion plus claire du statut de désabonnement.
✓Utilisez l'API REST (pull) pour les exportations de données par lots, les processus ETL et les tableaux de bord analytiques.
✓Utilisez les Webhooks (push) pour des actions en temps réel déclenchées par des événements, telles que les synchronisations CRM, la messagerie personnalisée et les déclencheurs de fidélité.
✓Les écouteurs de Webhooks doivent être sécurisés par SSL, répondre en moins de 10 secondes et être conçus pour gérer les événements en double de manière idempotente.
✓Les principaux cas d'utilisation couvrent l'hôtellerie (enrichissement du CRM en temps réel), le commerce de détail (analyses multicanales) et les événements (données de fréquentation vérifiées pour les sponsors).
✓L'API permet aux organisations de transformer leur infrastructure WiFi d'un centre de coûts en un actif de données stratégique avec un ROI clair et mesurable.

Résumé exécutif

Pour les responsables informatiques des sites multi-établissements (hôtels, chaînes de magasins, stades et centres de conférence), le réseau WiFi invité est bien plus qu'un simple service de commodité. C'est une source riche et continuellement alimentée de données de première main (first-party) capable de générer un impact commercial mesurable sur le marketing, les opérations et l'expérience client. L'API du Purple Portal fournit l'interface programmatique nécessaire pour libérer cette valeur à grande échelle. Elle permet aux équipes techniques d'aller au-delà des tableaux de bord analytiques intégrés et de créer des intégrations robustes et automatisées qui injectent des données visiteurs conformes au GDPR directement dans les systèmes d'exploitation clés : plateformes CRM, outils d'automatisation marketing, programmes de fidélité et entrepôts de business intelligence.

Ce guide est une référence pratique et exploitable destinée aux architectes de solutions, aux responsables informatiques et aux développeurs confirmés. Il détaille le modèle d'authentification, les points de terminaison (endpoints) disponibles, les schémas d'intégration et les scénarios de déploiement réels qui démontrent comment l'API Purple WiFi peut transformer un déploiement WiFi d'un centre de coûts en un actif de données stratégique. Que vous évaluiez l'API pour la première fois ou que vous planifiiez une intégration prête pour la production, ce document vous fournit les bases techniques et les cadres de décision nécessaires pour avancer en toute confiance.

Analyse technique approfondie

Authentification et versioning de l'API

L'API du Purple Portal utilise l'authentification par clé API, un modèle simple et sécurisé parfaitement adapté aux intégrations de serveur à serveur. Contrairement aux flux OAuth 2.0 qui nécessitent des cycles d'échange et de renouvellement de jetons, l'authentification par clé API consiste à inclure un secret statique dans les en-têtes de requête. Cette simplicité réduit la complexité de l'intégration sans compromettre la sécurité, à condition que la clé soit stockée de manière sécurisée et renouvelée périodiquement dans le cadre de votre politique standard de gestion des identifiants.

La version de production actuelle est la v1.7, qui a introduit plusieurs améliorations importantes par rapport à la v1.6.2. Plus important encore, la propriété unsubscribed dans l'objet de données utilisateur distingue désormais clairement un utilisateur qui s'est activement désinscrit du marketing après s'être préalablement abonné, d'un utilisateur qui ne s'est jamais abonné. Cette distinction est essentielle pour la conformité au GDPR et pour une segmentation précise de l'audience. De plus, les points de terminaison Visitors et Venues renvoient désormais une réponse HTTP 200 OK lorsqu'aucune donnée n'est trouvée, plutôt qu'une erreur 404 Not Found, ce qui causait auparavant des confusions dans la logique de surveillance et de gestion des erreurs.

Points de terminaison (endpoints) disponibles

L'API de Portal Company expose trois principales catégories de points de terminaison avec lesquelles les équipes informatiques interagiront régulièrement.

Point de terminaison	Méthode	Objectif
`/visitors`	GET	Récupérer les profils des visiteurs invités, y compris les données de contact, les données démographiques et l'historique des visites
`/venues`	GET	Récupérer les données au niveau du site et les métadonnées de configuration
`/unsubscribes`	GET	Récupérer la liste des utilisateurs qui se sont désinscrits des communications marketing

Tous les points de terminaison renvoient des données au format JSON. Le point de terminaison visitors est le plus couramment utilisé, car il expose toute la richesse des données de profil des clients collectées lors du parcours d'authentification sur le Captive Portal. Cela inclut le prénom, le nom, l'adresse e-mail, le genre, la date de naissance, le numéro de téléphone mobile, le code postal, le fournisseur d'authentification (par exemple, formulaire d'inscription, connexion sociale), le nombre de visites par établissement et tous les champs personnalisés configurés sur la splash page.

Limites de débit (Rate Limits)

Un avantage architectural clé de l'API de Purple Portal est qu'il n'y a pas de limites de débit. La plateforme est conçue pour supporter n'importe quel volume de requêtes ou de transactions, ce qui la rend idéale pour les déploiements à grande échelle où les scripts peuvent avoir besoin de traiter des milliers d'enregistrements d'établissements ou des millions de profils de visiteurs. Cela supprime une contrainte courante qui complique la conception de l'intégration avec d'autres plateformes et élimine le besoin de régulation des requêtes (throttling) ou de logique d'attente (back-off) dans votre code client.

Modèles d'intégration : Pull vs. Push

L'API de Purple WiFi prend en charge deux modèles d'intégration fondamentalement différents, chacun étant adapté à des cas d'usage distincts. Comprendre quel modèle appliquer dans un scénario donné est la décision d'architecture la plus importante que vous aurez à prendre.

Le modèle pull de l'API REST implique que votre système effectue des requêtes à la demande ou planifiées vers les points de terminaison de l'API pour récupérer des données. C'est l'approche correcte pour le traitement par lots, les rapports et l'informatique décisionnelle (business intelligence). Un script ETL nocturne qui extrait toutes les données des visiteurs de la veille pour les charger dans un entrepôt de données en est un exemple classique. Le modèle pull vous donne un contrôle total sur le moment et la quantité de données que vous récupérez.

Le modèle push des Webhooks implique que Purple envoie des données à votre système au moment précis où un événement spécifique se produit, en particulier lorsqu'un client s'authentifie sur le réseau WiFi. Votre système doit exposer un point de terminaison HTTP sécurisé par SSL et accessible publiquement (un "listener") capable de recevoir et de traiter ces charges utiles JSON POST. Le modèle Webhook est le choix idéal pour tout cas d'usage nécessitant des données en temps quasi réel, comme le déclenchement d'un message de bienvenue personnalisé, la mise à jour du statut "dernière visite" d'un client dans un CRM, ou la notification à un responsable d'établissement de l'arrivée d'un client VIP.

Structure de la charge utile des Webhooks

La charge utile JSON transmise par un Webhook Purple est structurée en quatre objets principaux, chacun fournissant une dimension contextuelle différente pour l'événement d'authentification.

Objet	Champs clés	Description
`client`	`mac`, `userAgent`	Identifiants au niveau de l'appareil
`company`	`id`, `name`, `uniqId`	Les détails du compte de votre entreprise
`venue`	`id`, `name`, `latitude`, `longitude`	L'établissement spécifique où l'authentification a eu lieu
`session`	`authenticationTime`	Horodatage ISO 8601 de l'événement d'authentification
`user`	`email`, `firstName`, `lastName`, `gender`, `provider`, `visitCountForVenues`, `customFields`	Données complètes du profil de l'invité

L'objet user.visitCountForVenues est particulièrement précieux pour les opérateurs multi-sites. Il fournit un décompte des visites par site ainsi que les horodatages firstVisit et lastVisit, vous permettant d'identifier les nouveaux visiteurs par rapport aux clients fidèles dès l'authentification — sans aucun appel API supplémentaire.

Guide d'implémentation

Prérequis et configuration

L'accès à l'API du portail nécessite une licence Engage. Une fois la licence obtenue, générez votre clé API depuis les paramètres du portail Purple. Pour le développement et les tests initiaux, Postman est l'outil recommandé ; Purple fournit un guide de configuration dédié pour configurer les bonnes variables d'environnement et les en-têtes de requête. Un fichier de démonstration PHP est également disponible pour les équipes préférant un point de départ avec script côté serveur.

Configuration d'une intégration Webhook

Le déploiement d'une intégration Webhook implique cinq étapes. Tout d'abord, créez et déployez votre point de terminaison d'écoute (listener) sur une URL accessible publiquement et sécurisée par SSL. Une fonction serverless (AWS Lambda, Azure Functions ou Google Cloud Functions) est un choix architectural pertinent : elle s'adapte automatiquement à l'échelle, génère un coût minimal à faible volume et gère les requêtes simultanées sans configuration. Deuxièmement, validez l'URL de l'écouteur dans le portail Purple en accédant à Management > Venues > Webhooks. Purple enverra une requête de test pour confirmer que le point de terminaison est accessible et renvoie l'en-tête wifiWebhookListener: 1 requis. Troisièmement, créez ou modifiez un LogicFlow dans le portail et ajoutez un nœud d'action Webhook, en sélectionnant votre URL validée. Quatrièmement, assurez-vous que le LogicFlow est défini sur le statut « En ligne ». Cinquièmement, associez le LogicFlow au parcours d'accès (Access Journey) concerné. À partir de ce moment, chaque authentification d'invité sur ce parcours déclenchera votre Webhook.

Gestion des tentatives et idempotence

Votre écouteur doit être conçu pour faire face aux réalités des systèmes distribués. Purple réessaiera de distribuer un Webhook ayant échoué après trois heures si votre écouteur ne répond pas (délai d'attente supérieur à 10 secondes) ou renvoie un statut d'erreur. Cela signifie que votre écouteur peut recevoir le même événement plusieurs fois. De plus, une seule visite d'invité peut déclencher plusieurs événements d'authentification — par exemple, lorsqu'un appareil se reconnecte après le verrouillage de l'écran, ou lorsqu'un utilisateur passe d'un point d'accès à un autre. Votre logique de traitement doit donc être idempotente : appliquer le même événement deux fois doit produire le même résultat que de l'appliquer une seule fois. Un modèle d'implémentation courant consiste à vérifier si une action (comme l'envoi d'un e-mail de bienvenue) a déjà été effectuée pour un identifiant d'utilisateur donné dans une fenêtre de temps définie avant de l'exécuter.

Bonnes pratiques

Plusieurs principes doivent guider tout déploiement en production de l'API Purple Portal. Déployez toujours sur la dernière version de l'API (v1.7) et mettez à jour vos chemins d'URL ainsi que votre logique d'analyse des réponses lors de la sortie de nouvelles versions. Traitez votre clé API comme un identifiant sensible : stockez-la dans un gestionnaire de secrets (tel que AWS Secrets Manager ou Azure Key Vault) plutôt que dans le code source ou les variables d'environnement sur des systèmes partagés. Pour les écouteurs de Webhooks, implémentez une journalisation structurée de chaque charge utile entrante et de chaque réponse afin de faciliter le débogage et les pistes d'audit. Respectez les champs unsubscribed et unsubscribedDate de l'objet utilisateur ; le traitement d'actions marketing pour des utilisateurs désabonnés constitue une violation du GDPR. Enfin, testez votre intégration face à l'ensemble des cas limites : utilisateurs sans adresse e-mail, utilisateurs avec des champs personnalisés nuls et événements d'authentification arrivant dans un ordre non chronologique.

Résolution des problèmes et atténuation des risques

Le mode de défaillance le plus courant dans une intégration de Webhook est un écouteur lent ou indisponible. Si le point de terminaison ne répond systématiquement pas dans un délai de 10 secondes, Purple désactivera automatiquement le Webhook après une période d'inactivité prolongée, ce qui nécessitera une re-vérification manuelle dans le portail. Pour atténuer ce risque, implémentez un point de terminaison de vérification de l'état (health check) sur le même serveur que votre écouteur et incluez-le dans la surveillance de votre infrastructure. Assurez-vous que votre écouteur effectue uniquement un traitement synchrone minimal avant de renvoyer une réponse 200 OK ; transférez tout calcul lourd ou appel d'API en aval vers une file d'attente asynchrone.

Pour les intégrations de l'API REST, le risque principal est l'obsolescence des données dans les systèmes en aval si la tâche de récupération planifiée échoue silencieusement. Implémentez des alertes sur vos scripts ETL pour informer l'équipe des opérations si une exécution échoue ou ne produit aucun résultat de manière inattendue. Lors de la migration de l'API v1.6.2 vers la v1.7, auditez tout le code qui fait référence au champ unsubscribed et au point de terminaison Unsubscribes, car le nom de la propriété a été corrigé de unsubcribers à unsubscribers dans la v1.7.

ROI et impact commercial

The business case for integrating with the Purple Portal API is well-established across multiple verticals. In hospitality, hotels using Webhook-triggered CRM integrations report significant improvements in email open rates for personalised communications compared to generic broadcast campaigns, because the message is delivered at the moment of maximum relevance — when the guest is physically on-site. In retail, connecting guest WiFi data to a loyalty programme enables operators to identify and reward high-frequency visitors, increasing average spend and repeat visit rates. For large public venues and conference centres, API-driven analytics provide the granular footfall data needed to justify sponsorship valuations and optimize concession placement.

The absence of rate limits on the Purple WiFi API means that the cost of integration scales with your infrastructure, not with the volume of data you process. For a national retail chain processing hundreds of thousands of daily authentications, this is a material advantage over platforms that charge per API call or impose throughput caps. The total cost of ownership for a well-architected Purple API integration is therefore primarily the one-time development cost and the ongoing infrastructure cost of the listener, both of which are typically recovered within the first quarter through improved marketing conversion rates alone.

Case Studies

Case Study 1: Hospitality — Whitbread Group

Whitbread, the UK's largest hotel and restaurant company, operates thousands of guest WiFi access points across its Premier Inn and restaurant estate. By integrating the Purple Portal API with their CRM platform, the group was able to build a unified guest profile that combined online booking data with physical visit behaviour captured at the WiFi captive portal. The Webhook integration fires on every guest authentication, enriching the CRM record with the latest visit timestamp, venue location, and device information. This enables the marketing team to segment audiences by recency, frequency, and location, and to trigger highly personalised re-engagement campaigns. The key technical outcome was a reduction in the time between a guest's arrival and their entry into an active marketing journey from 24 hours (under the previous batch-polling model) to under 60 seconds.

Case Study 2: Retail — Multi-Site Fashion Retailer

Un détaillant national de mode comptant plus de 80 magasins a déployé l'API de Purple Portal pour combler une lacune critique dans sa stratégie de données clients : il disposait de données solides sur le commerce électronique, mais n'avait pratiquement aucune visibilité sur le comportement des visiteurs en magasin. En connectant l'API Purple de WiFi invité à leur entrepôt de données existant via un processus ETL nocturne, ils ont créé pour la première fois une vue client multicanale. Le point de terminaison /visitors était interrogé chaque nuit pour chaque magasin, et les données étaient associées aux enregistrements de transactions d'e-commerce en utilisant l'adresse e-mail comme clé commune. En l'espace de trois mois, l'équipe d'analystes a identifié que les clients qui se connectaient au WiFi en magasin présentaient un panier moyen supérieur de 34 % lors de leur achat en ligne suivant, fournissant ainsi un argument commercial convaincant pour investir davantage dans l'expérience numérique en magasin. L'intégration n'a nécessité aucune modification de l'infrastructure e-commerce existante, démontrant la simplicité du modèle de requêtes de l'API REST.

Étude de cas 3 : Événementiel — Centre de conférence

Un grand centre de conférence au Royaume-Uni a utilisé l'API de Purple Portal pour fournir pour la première fois aux sponsors des données de fréquentation vérifiées. Auparavant, les rapports destinés aux sponsors reposaient sur des comptages manuels et des scans de badges, des méthodes fastidieuses et imprécises. En exposant via l'API des volumes de visiteurs agrégés et anonymisés par zone (associés aux identifiants de sites de la plateforme Purple), l'équipe événementielle a pu fournir aux sponsors des tableaux de bord en temps réel affichant le temps de séjour et le volume de visiteurs dans les zones sponsorisées. Les données étaient récupérées via l'API REST toutes les 15 minutes pendant les événements et affichées sur un portail sponsor personnalisé. Cette fonctionnalité a directement contribué à une augmentation de 22 % du taux de renouvellement des partenariats dès la première année, les sponsors pouvant désormais quantifier la portée de leurs activations grâce à des données de première main vérifiées.

Définitions clés

Webhook

Un mécanisme automatisé par lequel un serveur envoie une notification de données en temps réel (un push) à une autre application lorsqu'un événement spécifique se produit, via une requête HTTP POST.

Dans le contexte de Purple, un Webhook envoie une charge utile JSON contenant les données des visiteurs à votre système dès qu'un invité s'authentifie sur le réseau WiFi. Cela est essentiel pour le marketing en temps réel et les mises à jour du CRM.

REST API

Un style d'architecture standardisé pour la création de services web qui permet à un système de demander (ou d'extraire) des données d'un autre système en utilisant des méthodes HTTP standards telles que GET et POST.

Les équipes informatiques utilisent l'API REST de Purple pour écrire des scripts qui extraient des données globales sur les visiteurs et les sites afin de les analyser dans des outils de business intelligence comme Power BI ou Tableau.

Authentification par clé API

Un modèle de sécurité dans lequel l'accès à une API est accordé en fournissant un jeton secret unique (la clé) à chaque requête, généralement dans l'en-tête d'autorisation HTTP.

Cette méthode est plus simple qu'OAuth et idéale pour les intégrations de serveur à serveur. Vos scripts doivent inclure la clé API valide dans les en-têtes de requête pour accéder aux données de Purple.

Idempotence

Une propriété d'une opération signifiant qu'elle peut être appliquée plusieurs fois sans modifier le résultat au-delà de l'application initiale.

Votre écouteur de Webhook doit être idempotent. S'il reçoit deux fois le même événement d'authentification (ce qui peut arriver en raison de tentatives infructueuses ou de reconnexions d'appareils), il ne doit pas, par exemple, envoyer deux e-mails de bienvenue.

JSON (JavaScript Object Notation)

Un format d'échange de données textuel et léger, facile à lire pour les humains et à analyser ou générer pour les machines.

L'API de Purple et les Webhooks fournissent toutes les données au format JSON. Votre application devra analyser ce JSON pour extraire des champs tels que l'e-mail, le nom et le nombre de visites.

LogicFlow

L'outil visuel de glisser-déposer de Purple conçu pour créer des flux de travail automatisés de marketing et d'engagement qui peuvent déclencher des actions basées sur le comportement et le profil démographique des visiteurs.

Vous utilisez LogicFlow pour définir le parcours de l'invité. C'est là que vous associez votre Webhook, en indiquant au système de le déclencher lorsque l'utilisateur atteint l'état « En ligne » de son parcours d'accès.

Captive Portal

La page web qu'un utilisateur voit et avec laquelle il doit interagir avant de pouvoir accéder à un réseau WiFi public, nécessitant généralement une authentification ou la saisie de données.

La plateforme Purple alimente le Captive Portal, et les données saisies par l'utilisateur sur cette page (par exemple, le nom, l'e-mail, les champs personnalisés) sont celles qui deviennent disponibles via l'API du portail.

GDPR (Règlement général sur la protection des données)

Une loi complète sur la confidentialité des données dans l'Union européenne qui régit la collecte, le traitement et le stockage des données personnelles des résidents de l'UE.

L'API de Purple fournit les outils nécessaires pour créer des intégrations conformes au GDPR, comme le respect du statut de désabonnement d'un utilisateur et l'activation de l'exportation des données pour les demandes d'accès des personnes concernées. La mise à jour v1.7 de l'API a spécifiquement amélioré la clarté du champ de désabonnement pour favoriser la conformité.

ETL (Extraction, Transformation, Chargement)

Un processus d'intégration de données qui consiste à extraire des données d'un système source, à les transformer dans le format requis et à les charger dans un système de destination tel qu'un entrepôt de données.

Le modèle d'extraction de l'API REST est généralement implémenté sous la forme d'un processus ETL, où les données sont extraites du point de terminaison /visitors de Purple, transformées pour correspondre au schéma de destination, et chargées dans un CRM ou un entrepôt de données.

Exemples concrets

Un hôtel de 200 chambres souhaite ajouter automatiquement les nouveaux utilisateurs du WiFi invité à son parcours Salesforce Marketing Cloud et envoyer un e-mail de bienvenue.

Dans le Purple Portal, validez une nouvelle URL de Webhook pointant vers un point de terminaison sécurisé (par exemple, une fonction serverless sur AWS Lambda). 2. Créez un LogicFlow « En ligne » qui inclut le nœud Webhook, configuré pour utiliser l'URL validée. 3. Attribuez ce LogicFlow au parcours d'accès WiFi invité de l'hôtel. 4. La fonction serverless reçoit la charge utile JSON lors de l'authentification de l'invité, extrait l'e-mail et le nom de l'utilisateur, puis effectue un appel API vers Salesforce Marketing Cloud pour ajouter l'utilisateur au parcours « Nouvel invité ». 5. La fonction renvoie une réponse HTTP 200 OK à Purple dans la fenêtre de délai d'expiration de 10 secondes.

Commentaire de l'examinateur : Cette solution utilise correctement le modèle de Webhook en temps réel, idéal pour des actions immédiates telles que l'envoi d'un e-mail de bienvenue. L'utilisation d'une fonction serverless est un moyen rentable et évolutif d'héberger le point de terminaison d'écoute. Une alternative consisterait à interroger le point de terminaison de l'API /visitors, mais cela introduirait un délai allant jusqu'à 24 heures et serait nettement moins efficace pour une exigence en temps réel.

Une chaîne de vente au détail comptant 50 magasins souhaite créer un tableau de bord centralisé dans Power BI pour analyser les tendances des visiteurs sur l'ensemble des sites.

Créez un script (par exemple, en Python) qui s'exécute selon un calendrier nocturne. 2. Le script s'authentifie auprès de l'API Purple Portal à l'aide de la clé API de l'entreprise. 3. Il parcourt chacun des 50 identifiants de site, en effectuant un appel au point de terminaison /visitors pour chacun d'eux afin de récupérer toutes les données des visiteurs de la veille. 4. Le script transforme et charge ces données dans un entrepôt de données central (par exemple, Azure SQL ou BigQuery). 5. Power BI est connecté à l'entrepôt de données pour créer le tableau de bord analytique multi-sites.

Commentaire de l'examinateur : Il s'agit d'un processus ETL (Extract, Transform, Load) classique et correspond à l'utilisation correcte du modèle d'interrogation de l'API REST. Il convient à l'agrégation de données à grande échelle et non en temps réel pour la business intelligence. L'utilisation d'un entrepôt de données centralisé est une bonne pratique pour les performances et l'évolutivité lors du traitement de données provenant de sources multiples. L'absence de limites de débit sur l'API Purple signifie que le script peut traiter les 50 sites sans problème de limitation.

Questions d'entraînement

Q1. Un stade souhaite identifier les détenteurs d'abonnements VIP lorsqu'ils se connectent au WiFi et envoyer une notification sur le tableau de bord du responsable de l'accueil le plus proche. Quel modèle d'intégration doivent-ils utiliser et pourquoi ?

Conseil : Prenez en compte la vitesse requise pour la notification et déterminez si l'action est déclenchée par un événement.

Voir la réponse type

Ils doivent utiliser le modèle Webhook (push). Il s'agit d'une exigence en temps réel : lorsque le VIP se connecte, un Webhook se déclenche immédiatement vers un service qui recherche l'adresse e-mail ou l'adresse MAC de l'utilisateur dans la base de données des abonnés. Si une correspondance est trouvée, il envoie une notification au tableau de bord d'accueil concerné. Un modèle REST API (pull) serait trop lent, car il repose sur des interrogations périodiques et pourrait introduire des retards de plusieurs minutes ou heures.

Q2. Vous êtes chargé de créer un rapport quotidien des 10 points de vente les plus visités de votre chaîne nationale de cafés. Comment récupéreriez-vous les données nécessaires depuis Purple ?

Conseil : S'agit-il d'une exigence de rapport en temps réel ou par lot ? Quel point de terminaison interrogeriez-vous ?

Voir la réponse type

Il s'agit d'une tâche de reporting par lot, le modèle REST API (pull) est donc approprié. Un script planifié s'exécuterait quotidiennement, interrogerait le point de terminaison /visitors pour chaque point de vente, agrégerait le nombre de visites de la veille, puis calculerait le top 10. Il n'y a pas besoin de la notification quasi instantanée fournie par les Webhooks. L'absence de limites de débit signifie que tous les points de vente peuvent être interrogés en une seule exécution de script sans risque de limitation.

Q3. Votre point de terminaison d'écoute Webhook échoue. Vous vérifiez les journaux et constatez une erreur de délai d'attente (timeout). Quelle est la cause la plus probable selon la documentation de Purple, et quelles en sont les deux conséquences immédiates ?

Conseil : Pensez aux exigences de performance d'un écouteur et à ce que fait Purple lorsqu'il ne peut pas livrer une charge utile.

Voir la réponse type

La cause la plus probable est que l'écouteur met plus de 10 secondes à traiter la charge utile JSON entrante et à renvoyer une réponse 200 OK. Les deux conséquences immédiates sont : (1) Purple cessera d'essayer d'envoyer la requête en cours et la replacera dans la file d'attente pour une nouvelle tentative dans 3 heures, ce qui signifie que la livraison des données est retardée ; et (2) si cela persiste pendant une période prolongée, Purple désactivera automatiquement et complètement le Webhook, nécessitant une revérification manuelle dans le portail avant de pouvoir le réactiver.

Continuer la lecture de cette série

Intégration de CommScope Ruckus avec Purple WiFi : Guide d'installation et de configuration

Ce guide de référence technique fournit un manuel de configuration faisant autorité pour l'intégration des architectures CommScope Ruckus avec Purple WiFi. Il détaille les déploiements étape par étape pour les Captive Portals de WiFi invité, le WiFi personnel sécurisé via 802.1X et l'isolation réseau multi-locataire à l'aide de Ruckus Dynamic PSK.

Intégration des points d'accès Allied Telesis avec Purple WiFi

Ce guide fournit un manuel de configuration complet pour l'intégration des points d'accès Allied Telesis de la série TQ avec Purple WiFi. Il traite de la redirection vers le Captive Portal externe, de l'authentification RADIUS 802.1X et de l'orientation VLAN dynamique à l'aide de clés prépartagées privées (PPSK) pour des déploiements multi-locataires sécurisés.

Intégration des points d'accès Grandstream GWN avec Purple WiFi

Ce guide de référence technique officiel détaille comment intégrer les points d'accès Grandstream GWN avec le Guest WiFi de Purple et sa plateforme d'analyse. Il couvre la configuration du Captive Portal Grandstream, les paramètres RADIUS AAA, la configuration du walled garden, l'authentification sécurisée du personnel en 802.1X avec routage dynamique des VLAN, et la segmentation PPSK multi-tenant - offrant ainsi des instructions étape par étape directement exploitables pour les MSP et les équipes informatiques déployant du WiFi invités et personnel à grande échelle.