Seu hotspot funciona. O cliente conecta, navega, desconecta. E você fica sem nome, sem telefone, sem nenhum dado que justifique o investimento naquele roteador.
A peça que falta entre “liberar Wi-Fi” e “capturar cliente” quase sempre é uma API para hotspot Wi-Fi. É ela que liga o roteador ao portal, o portal ao banco de dados, o banco ao CRM. Sem ela, cada camada opera isolada. Com ela, o momento em que alguém aceita os termos do Wi-Fi vira lead qualificado, sessão monitorada e oportunidade de recompra.
O problema é que o assunto está fragmentado entre documentações técnicas, fóruns desatualizados e manuais de firmware. Ninguém junta as peças para quem precisa decidir qual camada automatizar primeiro. Este guia mapeia as 6 camadas de integração, compara os caminhos do mercado e entrega critérios concretos de escolha.
Veja mais vídeos como esse em nosso canal do YouTube!
O que é (e o que não é) uma API de hotspot Wi-Fi
Uma API de hotspot Wi-Fi é uma interface programável que permite criar, configurar, monitorar ou integrar alguma parte do serviço de acesso sem fio. “Alguma parte” é o detalhe que muda tudo. Provisionar SSIDs, autenticar clientes, emitir vouchers, limitar banda, coletar opt-in e alimentar um CRM são operações diferentes, quase sempre feitas por componentes diferentes.
Na prática, quem busca “apis para hotspot wi-fi” pode estar atrás de cinco coisas distintas:
- Implementação: como montar o captive portal e liberar o cliente após login.
- Integração: como enviar dados do Wi-Fi para um sistema externo (ERP, CRM, WhatsApp).
- Operação: como configurar dezenas ou centenas de pontos de acesso de uma vez.
- Monetização: como vender acesso, emitir vouchers ou capturar leads pelo Wi-Fi.
- Roaming seguro: como eliminar login manual para clientes recorrentes (Passpoint, OpenRoaming).
E a escala justifica essa diversidade. A Cisco projetou quase 628 milhões de hotspots públicos para 2023, ante 169 milhões em 2018. A IDC registrou US$ 2,9 bilhões no mercado WLAN corporativo mundial no 4T25, alta de 13,9% em um ano. Configurar tudo isso manualmente não é viável. API deixou de ser luxo técnico e virou infraestrutura operacional.
Do lado dos padrões abertos, dois documentos definem o comportamento esperado. A RFC 8910 especifica como o roteador informa ao dispositivo que existe um portal cativo, usando opções DHCP e Router Advertisement IPv6. A RFC 8908 define a API HTTP do portal: o dispositivo consulta o estado da sessão, descobre a URL de login e sabe quando a captividade terminou, tudo via JSON e com exigência de validação de certificado TLS.
O que uma API de hotspot não faz: substituir cobertura de rádio, backhaul de internet ou access point físico. Ela orquestra o que já existe. Se o AP não cobre a área, nenhuma API vai salvar a experiência.
Sabendo o que a API é (e o que não é), o passo seguinte é entender onde ela se encaixa. São 6 camadas, e confundir uma com a outra é o erro mais comum em projetos de hotspot.
As 6 camadas de integração de um hotspot
Uma implementação completa de hotspot pode ser lida como uma pilha de 6 camadas. Cada uma tem sua interface, seu papel e seu nível de complexidade.
| Camada | O que faz | Interface típica | Exemplo |
|---|---|---|---|
| 1. Rádio / AP | Anuncia SSID, gerencia associação e segurança | Protocolo proprietário do AP | UniFi, Meraki, MikroTik |
| 2. Gateway | Permite, limita ou bloqueia tráfego | Firewall, walled garden, NAT | Coova-Chilli, openNDS, nftables |
| 3. Portal cativo | Coleta login, voucher, pagamento ou consentimento | HTTP/HTTPS, RFC 8908/8910 | Splash page, login social |
| 4. AAA | Autentica, autoriza e contabiliza sessões | RADIUS, EAP | FreeRADIUS, RADIUS do controller |
| 5. Controller | Provisiona sites, SSIDs, políticas e telemetria | REST API, SDK, WebSocket | Meraki Dashboard API, Aruba Central |
| 6. Identidade / CRM | Recebe eventos, armazena dados, dispara ações | Webhooks, REST, MQTT | CRM, Wi-Fi marketing, WhatsApp |
O fluxo clássico: cliente associa ao SSID, recebe IP via DHCP, descobre o portal cativo, acessa a tela de login, se autentica, o portal chama a API do gateway para liberar a sessão, o gateway aplica políticas de tempo/banda/volume, e eventos alimentam a camada 6 em paralelo.
A confusão mais frequente é tratar REST e RADIUS como concorrentes. Não são. REST serve para controle e integração de negócio (camadas 5 e 6). RADIUS fica no caminho de autenticação e contabilização (camada 4). O OpenWISP combina Coova-Chilli, FreeRADIUS, VPN e REST API de RADIUS em uma mesma arquitetura, cada componente na sua camada.
Para quem opera um estabelecimento comercial (restaurante, academia, hotel, clínica), as camadas que realmente importam são a 3 e a 6: o portal que captura e o sistema que transforma dado em ação. As camadas 1 a 5 são infraestrutura. Precisam funcionar, mas não precisam ser construídas do zero quando existe uma plataforma que já resolve isso.
A questão, então, passa a ser: construir do zero, contratar um SaaS ou montar com código aberto? Cada caminho resolve um problema e cria outro.
Proprietárias, SaaS ou open source: comparativo direto
APIs proprietárias (do fabricante do AP)
MikroTik, Meraki, UniFi, Aruba Central e RUCKUS One oferecem APIs ligadas ao hardware ou à nuvem do fabricante. A API do RouterOS (MikroTik) opera via TCP nas portas 8728 e 8729, com autenticação por usuário e senha e automação de comandos, incluindo o HotSpot com autenticação local ou RADIUS, walled garden e contabilização. A External Hotspot API da UniFi tem escopo mais restrito: redireciona o cliente a um portal externo e autoriza com limites de tempo, dados e taxa.
O risco é lock-in. Migrar de MikroTik para UniFi significa reescrever a integração. Se o fabricante muda a versão da API, sua automação quebra.
Plataformas SaaS
Plataformas SaaS como IronWiFi, Purple e Cloud4Wi entregam portal, gestão de usuários, vouchers, analytics e CRM em uma interface pronta. A API REST da IronWiFi, por exemplo, expõe redes, venues, portais, usuários, vouchers e relatórios, com Bearer token e limite de 100 requisições por minuto. A Cloud4Wi opera portal cloud independente de hardware, com SSO, passwordless, OTP, opt-in e analytics.
A vantagem é speed: em vez de montar o stack, você configura. A desvantagem é que os dados vivem na nuvem do fornecedor, e você depende do rate limit, do contrato e da política de exportação.
Stack open source
O OpenWISP oferece controller com REST API, provisionamento, VPN e certificados X509. O TIP OpenWiFi entrega uma pilha desagregada com NBI RESTful e telemetria MQTT. O openNDS é um gateway leve de captive portal entre LAN pública e internet.
O ganho é controle total e menor dependência de fornecedor. O custo é real: você opera PKI, AAA, atualizações, segurança e suporte. Para uma empresa de TI ou provedor com equipe técnica, pode funcionar. Para um restaurante ou academia, dificilmente.
| Tipo | Vantagem principal | Custo oculto | Melhor para |
|---|---|---|---|
| Proprietária | Integração nativa com o AP | Lock-in, mudança de API | Redes homogêneas (só MikroTik, só UniFi, etc.) |
| SaaS | Portal, dados e CRM prontos | Dados fora da empresa, rate limit, contrato | Quem quer resultado rápido sem montar stack |
| Open source | Controle e portabilidade | Engenharia, PKI, suporte, upgrades | Provedores e integradores com equipe técnica |
Nenhum dos três caminhos é universalmente melhor. A escolha depende de onde você quer gastar energia: na infraestrutura ou no resultado de negócio. E “resultado de negócio” tem critérios muito específicos.
Critérios práticos para escolher a API certa
Antes de comparar documentação, responda cinco perguntas:
- Qual camada você quer automatizar? Se é liberar acesso após login social, precisa de portal com API (camada 3). Se é provisionar 200 APs em 50 filiais, precisa de controller com API (camada 5). Se é alimentar CRM e disparar mensagem, precisa de webhooks e eventos (camada 6). A maioria dos projetos de Wi-Fi marketing opera nas camadas 3 e 6.
- Quantos fabricantes de AP você tem? Se a rede é 100% MikroTik e vai continuar assim, a API do RouterOS resolve. Se você atende clientes com equipamentos variados, uma plataforma hardware-agnostic elimina a necessidade de um adaptador por fabricante.
- Qual é o limite aceitável de requisições? 100 por minuto pode ser suficiente para 10 locais. Para 500 locais com picos simultâneos, o rate limit vira gargalo. Pergunte antes de assinar.
- Os dados são exportáveis? Se amanhã você trocar de plataforma, consegue levar a base de leads, os consentimentos registrados e o histórico? Se a resposta for “não” ou “depende”, é lock-in disfarçado.
- A API registra consentimento e finalidade? LGPD e Marco Civil não são opcionais. Se a API captura e-mail e telefone mas não registra opt-in, base legal e finalidade, o dado é um passivo jurídico, não um ativo de marketing.
Um erro frequente é escolher pela feature list. A API que faz mais coisas nem sempre resolve o seu problema. Uma plataforma de Wi-Fi marketing com captive portal, opt-in e integração nativa com WhatsApp pode entregar mais resultado para um PDV do que um controller enterprise com 200 endpoints que ninguém vai usar.
E por falar em dados capturados, existe uma camada que separa quem faz Wi-Fi marketing de verdade de quem só oferece internet grátis: a governança de privacidade.
Privacidade e LGPD: o que a API precisa garantir
Toda API de hotspot que captura dados pessoais (e-mail, telefone, MAC address, localização) precisa operar com três princípios: finalidade, consentimento e minimização. O tema de compliance para hotspot Wi-Fi abrange esses requisitos em profundidade, incluindo aspectos legais e implementação prática.
O Marco Civil da Internet (Lei 12.965/2014) determina que o provedor de conexão mantenha registros de conexão por um ano, em ambiente controlado e sob sigilo. A ANPD é a autoridade que fiscaliza o tratamento de dados pessoais conforme a LGPD. Na prática, a API do seu hotspot deve:
- Registrar o consentimento (quando, onde, para quê).
- Separar dados de conexão (obrigatórios por lei) de dados de marketing (dependem de opt-in).
- Permitir exclusão e portabilidade.
- Minimizar identificadores: MAC address vinculado a perfil já é dado pessoal.
O caso LinkNYC mostra o risco. A rede pública de Nova York declarava na política de privacidade que retinha MAC addresses anonimizados por um ano. A NYCLU questionou publicamente se a anonimização era real. A distância entre “política declarada” e “execução auditável” é o espaço onde a API precisa atuar: registrando, separando e permitindo auditoria real.
Outro ponto que costuma passar batido: a EFF alerta que portais cativos podem interferir com HTTPS ao redirecionar tráfego criptografado. Se o sistema instrui o usuário a ignorar alertas de certificado, o dano de segurança supera o benefício do login. A RFC 8908 resolve parte disso ao padronizar a descoberta do portal via JSON, sem interceptação.
Para hotspot comercial no Brasil, a recomendação é clara: documente finalidade, base legal, prazo de retenção e canal de exclusão. E garanta que a plataforma suporte isso via API, não apenas em um PDF de termos que ninguém lê. Uma pesquisa da Wireless Broadband Alliance com 170 executivos mostrou que 78% apontaram segurança e privacidade como prioridade. O mercado já entendeu que sem governança, escala vira risco.
Se tudo isso parece complexo demais para montar sozinho, é porque é. Operar as 6 camadas por conta própria exige engenharia, tempo e manutenção contínua. É por isso que plataformas prontas de Wi-Fi marketing existem: para abstrair a infraestrutura e entregar o que importa (lead capturado, sessão rastreada, follow-up automático via WhatsApp). Para provedores de internet, empresas de TI e agências, existe a possibilidade de revender essa solução como SaaS white label, gerando receita recorrente sem precisar construir uma plataforma do zero.
Perguntas frequentes
O que é uma API de hotspot Wi-Fi?
É uma interface programável que permite criar, configurar, monitorar ou integrar alguma parte do serviço de acesso Wi-Fi. Pode servir para provisionar SSIDs, autenticar clientes, emitir vouchers, consultar sessões ou enviar eventos para sistemas externos. Não existe uma API única que cubra todas essas funções.
REST e RADIUS são a mesma coisa?
Não. REST é a interface de controle e integração de negócio (provisionar sites, consultar dados, disparar ações). RADIUS é o protocolo de autenticação, autorização e contabilização no caminho de acesso à rede. Operam em camadas diferentes e são complementares.
Preciso programar para usar APIs de hotspot?
Depende do caminho. APIs proprietárias e open source exigem conhecimento técnico. Plataformas SaaS de Wi-Fi marketing abstraem a complexidade e entregam portal, captura de leads e CRM prontos, sem exigir programação do gestor do estabelecimento.
Qual API funciona melhor para MikroTik?
A API do RouterOS opera via TCP nas portas 8728/8729 e permite automação de comandos do HotSpot, incluindo autenticação local ou RADIUS. Para captura de leads, integração com CRM e automação de mensagens, é necessário conectar uma camada de software acima do RouterOS.
A LGPD se aplica ao Wi-Fi do meu estabelecimento?
Sim, sempre que o hotspot captura dados pessoais (e-mail, telefone, MAC address vinculado a perfil). O Marco Civil exige retenção de registros de conexão por um ano. A LGPD exige base legal, finalidade, consentimento quando aplicável e canal de exclusão. A API deve registrar tudo isso de forma auditável.
Posso revender uma solução de hotspot com marca própria?
Sim. Plataformas white label permitem que provedores, empresas de TI e agências operem um hotspot social com sua marca, revendendo como SaaS e gerando receita recorrente mensal. A integração via API fica por conta da plataforma, não do revendedor.
