What the built-in Omada portal does,
and what it does not
The Omada portal is a good authentication tool. It was never meant to be a marketing tool, and pretending otherwise wastes your time.
Omada handles this on its own
Omada does not do this
How VoqadoWiFi sits on your Omada network
Every Omada login becomes a guest record
The controller hands VoqadoWiFi the device MAC, the access point MAC, and the SSID. Your branded form collects the email, name, phone, and consent. All of it lands in one guest table that recognises the same person the next time they walk in.
Self-hosted, hardware controller, or Omada Cloud
The integration covers a software controller on your own server, an Omada hardware controller, and cloud-managed deployments. You are not forced onto one hosting model to make the portal work.
Self-signed certificates are tolerated
Most on-premise Omada installs run with the certificate they shipped with. VoqadoWiFi does not make you obtain a public certificate for the controller before the authorisation call will go through.
Review requests fired from real session data
Because the platform knows when the session started and ended, the review request can wait until the visit is genuinely over rather than interrupting someone mid-meal.
Campaigns to a list you own
The contacts captured through the Omada portal are yours to segment and email. Nothing about that list is locked inside the controller or tied to a specific access point.
Test Connection before a guest ever sees it
Enter the controller URL, site, and credentials in the dashboard and run Test Connection. It reports reachability, whether the controller is cloud or self-hosted, and the round-trip latency, so you find the problem on your own time.
Connecting your Omada controller
Four steps, all of them reversible. Nothing here touches your production SSID policy.
Create the location in VoqadoWiFi
Add the venue and set its network vendor to Omada. This tells the platform which redirect format to expect and which authorisation path to use when a guest submits the form.
Point the Omada guest portal at VoqadoWiFi
In your Omada controller, open the portal configuration for the guest SSID and switch the authentication type to external portal. Set the portal URL to the VoqadoWiFi address shown for that location, and make sure the VoqadoWiFi domain is permitted in the pre-authentication walled garden so an unauthorised device can actually load the page.
Enter your controller details and test
Back in VoqadoWiFi, add the controller URL, the site, and the credentials the platform should use. Press Test Connection. A pass means VoqadoWiFi can reach the controller and issue the authorisation; a fail tells you which layer broke before any guest hits it.
Join the SSID yourself and confirm
Take a phone that has never been on the network, join the guest SSID, and walk the flow. You should see your branded page, get online after submitting, and find a new record in the guest list within seconds. Test on a fresh device, since an already authorised MAC will skip the portal entirely.
The five failures that actually happen
Nearly every Omada portal problem is one of these. Work down the list before you open a ticket.
The portal page never appears
The guest device cannot reach the VoqadoWiFi page while it is unauthenticated.
Check the pre-authentication walled garden in the Omada controller. Until the VoqadoWiFi domain is permitted there, the redirect points at a page the device is not yet allowed to load, and the guest gets a blank screen or a timeout instead of a login form.
The form submits but the guest stays offline
The redirect worked, but the authorisation call back to the controller did not.
This is the controller side, not the portal side. Run Test Connection in the dashboard. If it cannot reach the controller, the controller is not reachable from the internet, the URL or port is wrong, or a firewall is dropping the call. If it reaches the controller but the authorisation fails, the credentials or the site value are wrong.
Test Connection reports a TLS or certificate error
The controller presents a certificate the connection is refusing.
Self-signed certificates on self-hosted controllers are tolerated by the integration. If you still see a TLS failure, the usual causes are a hostname that does not match the certificate, a proxy in front of the controller terminating TLS oddly, or an incomplete certificate chain. Try the controller URL exactly as your browser reaches it.
One device works, the next one does not
The second device was already authorised, or the SSID is not the one you configured.
Omada remembers authorised MAC addresses for the length of the session policy, so a device that logged in earlier goes straight online without touching the portal. Test with a device that has never joined, or clear the authorised client from the controller first. Also confirm the portal is attached to the exact SSID you are joining rather than a second guest network.
Guests appear in the dashboard with no session details
The controller redirect is missing parameters.
The device MAC, access point MAC, and SSID all arrive as query parameters on the redirect. If they are absent, the portal URL was probably entered with its own query string that collided with the controller's, or the redirect was configured somewhere other than the external portal field. Re-enter the portal URL exactly as VoqadoWiFi shows it.
What gets captured at an Omada login
Some of it comes from your form. The rest is handed over by the controller in the redirect.
What it costs to connect Omada
The integration is not a paid add-on. Start on the free plan and prove the flow before you spend anything.
25 logins per month, 1 location. Enough to connect the controller and watch a real guest complete the flow.
For venues running the portal as a live marketing channel rather than an experiment.
Quoted for larger estates and multi-site groups. Talk to sales about your controller topology.
Omada captive portal questions
Answered by people who have actually debugged this integration.