Appearance
Portals: captive portal, WiFi Enterprise and buy panel
What the guest sees. Three parallel sets of designer, journey, login methods and configuration — one for free or voucher guest Wi-Fi, one for 802.1X enterprise onboarding, one for selling access — plus the media library they share.
Nearly every page below is permission-gated. If a colleague cannot see one, that is their role rather than a fault — Roles is where to look.
Captive Portal
Page Designer
/admin/captive-portal/designer
The gallery of captive portal templates — the guest login pages for the free/voucher-based portal, built in a drag-and-drop (GrapesJS) editor.
When you would open it. Building or restyling a guest login page, or checking which template is marked as the tenant's default.
Not enough on its own: a published template only reaches a guest once a Journey references it and a Zone is set to run that journey.
Needs the view-portal-templates permission.
Journey
/admin/captive-portal/journey
The list of captive portal journeys — each a named, draft-or-published guest login flow that strings together templates, login methods and what happens after login.
When you would open it. Building a new guest login flow, checking which journeys are published, or seeing which zones currently run a given journey.
Before it has anything on it. A journey has to be published and assigned to a zone before it carries any guest traffic — a draft journey with nothing attached is normal mid-build.
Needs the view-journey permission.
Login Methods
/admin/captive-portal/login-method
The identity sources guests can sign in or register with on the captive portal, grouped into login, registration, recovery and utility categories — one-click, voucher, SMS/WhatsApp/email OTP, social, payment, Active Directory/LDAP/SAML/Okta, sponsored and public signup, and more.
When you would open it. Turning on a new sign-in or registration option for guest login, or checking why a method you expect to see isn't listed.
Before it has anything on it. Most methods need a matching connector (SMS, WhatsApp, SMTP, Active Directory, LDAP, SAML, Okta, OAuth2 or payment gateway, set up under Connectors) before their own form has anything to select; a handful — one-click, default login, voucher login, QR login — need only a profile.
Needs the view-signin-method permission.
Configuration
/admin/captive-portal/configuration
Tenant-wide captive portal behaviour — session auto-disconnect, MAC auto-registration, the continue-login popup, autologin (cookie, MAC and browser fingerprint), password policy — plus the firewall, profile, account and 3rd-party policy tables reached from the same page.
When you would open it. Tuning how the portal behaves across every zone at once, or managing the firewall/profile/account/3rd-party policy lists that zones and journeys reference.
Before it has anything on it. A published portal template and at least one active controller for some of the sub-tabs' dropdowns (redirect pages, firewall scoping) to have anything to offer — the main settings tab works regardless.
Needs the view-portal-templates permission.
Zones Mapping
/admin/captive-portal/zones
How Kiwire tells which zone a guest's connection belongs to — one row per zone, each carrying detection rules (SSID, VLAN, NAS ID, IP/IPv6, controller zone) and the journey that runs for guests it matches.
When you would open it. Mapping a controller/SSID/VLAN to a zone, checking which journey a zone runs and whether it's published, or chasing down why guests keep landing in the wrong journey — an over-broad catch-all rule shadowing a more specific zone shows as a warning right on this page.
Before it has anything on it. A zone needs at least one detection rule to ever match a guest (a rule with every field left blank is a catch-all, not "no rule"); without a published, active journey assigned it's an inert entry.
Forced profile is a name, not an ID: the "Forced profile" field on a zone stores the profile's name, not its numeric id — renaming a profile updates every zone that forces it, but a profile deleted out from under a zone leaves that zone's forced-profile string pointing at nothing.
Needs the view-zones permission.
Bypass Devices
/admin/system/bypass-devices
Devices that get online without the captive portal, on two tabs. Approved devices: a list kept in Kiwire of TVs, streaming sticks and consoles that skip the portal on any controller brand, through MAC login on the controller or automatic sign-in on the portal. Router rules (MikroTik): a MAC/IP rule written straight onto a MikroTik router.
When you would open it. Letting room TVs and a guest's streaming stick online without anyone signing in — the stick can follow the guest's account and stop at check-out — or whitelisting a kiosk or printer on one router.
Before it has anything on it. Approved devices: the switch at the top of the tab turned on, and MAC login on the controller (or devices that open the portal in a browser). Router rules: a MikroTik router with its API user on the Device Controller record.
Where each list lives: approved devices are kept in Kiwire and decided at every connection, so their sessions are recorded like a guest's. Router rules are read live from the router and leave no session or report.
Needs the view-bypass-devices permission.
→ Letting TVs and other devices skip the portal
Rules
/admin/captive-portal/rules
A visual, trigger-condition-action automation builder for the captive portal — on a login event (form submitted, a page visited, a login error) it can check conditions (zone, guest type, time of day, day of week, a form field's value) and fire actions (push data to a webhook or Google Sheet, send an SMS/email/WhatsApp notification, force a RADIUS CoA, write a log line).
When you would open it. Automating something around a login event — notifying staff on a failed login, forcing a profile change via CoA when a form field matches, or pushing enrollment data to an external system — without touching a login method's own form.
Before it has anything on it. The rule's active toggle switched on (an inactive rule never fires) and, for the webhook, Google Sheet or notification actions, the relevant connector already set up under Connectors for the action to have somewhere to send to.
Needs the view-portal-rules permission.
WiFi Enterprise
Page Designer
/admin/wifi-enterprise/designer
The gallery of WiFi Enterprise portal templates — the pages a guest sees while self-enrolling a device onto the 802.1X SSID, before Kiwire hands them a device profile to install.
When you would open it. Building or restyling the enrollment page for the enterprise network, or checking which template is currently marked as the tenant's default.
Not enough on its own: a published template only reaches a guest once a Journey references it and a Portal Configuration runs that journey for a given SSID.
Needs the view-enterprise-templates permission.
Journey
/admin/wifi-enterprise/journey
The list of WiFi Enterprise journeys — each a named, draft-or-published enrollment flow that ties a template, a login method and certificate issuance together for guests joining the 802.1X SSID.
When you would open it. Building a new enrollment flow, checking which journeys are published, or seeing which portal configurations (SSIDs) currently run a given journey.
Before it has anything on it. A journey has to be published and assigned to a portal configuration before it actually runs for anyone — a draft journey with nothing attached is normal mid-build, but it won't carry any guest traffic yet.
Needs the view-enterprise-journey permission.
Login Methods
/admin/wifi-enterprise/login-method
The identity sources guests can sign in with during enterprise enrollment — a registered Kiwire account, or Google, Microsoft Entra, Active Directory, WhatsApp or SAML — and the enabled or disabled instances configured for each.
When you would open it. Turning on a new sign-in option for the enrollment flow, or checking why a particular method isn't showing up as a choice.
Before it has anything on it. Every method except the built-in registered-account one needs its matching connector (Google, Microsoft, AD, WhatsApp or SAML, set up under Connectors) before its own form has anything to select.
Needs the view-enterprise-login-method permission.
Configuration
/admin/wifi-enterprise/portal-config
The enterprise portal configurations — one per SSID/slug — that each run a journey and switch on options like the certificate panel and Passpoint/EAP-TTLS device profiles.
When you would open it. Wiring a new enterprise SSID to a journey, checking which configs are active, or turning on certificate-based device profiles for one.
Before it has anything on it. A current platform RADIUS certificate (managed by Synchroweb for the whole platform) for a config to actually hand out working device profiles — guests can't download one while it's expired — and a journey assigned, since a config with none is inert.
Needs the view-enterprise-configs permission.
Buy Panel
Page Designer
/admin/buy-panel/designer
The gallery of buy panel templates — the pages a guest sees on the paid-access purchase flow, built in the same drag-and-drop (GrapesJS) editor as the captive portal designer but on its own template store.
When you would open it. Building or restyling the purchase page for paid WiFi access, or checking which template is marked as the tenant's default.
Not enough on its own: a published template only reaches a guest once a Buy Panel Journey references it and a Buy Panel Configuration (a URL slug, not a zone) runs that journey.
Needs the view-buy-panel-designer permission.
Journey
/admin/buy-panel/journey
The list of buy panel journeys — each a named, draft-or-published purchase flow that ties buy panel templates and buy panel login methods together, distinct from captive portal journeys.
When you would open it. Building a new purchase flow, checking which journeys are published, or seeing which buy panel configs (URL slugs) currently run a given journey.
Before it has anything on it. A journey has to be published and assigned to a buy panel configuration before it carries any guest traffic.
Needs the view-buy-panel-journey permission.
Login Methods
/admin/buy-panel/login-method
The identity and payment sources guests can use on the buy panel — registered account, Google/Microsoft Entra/social login, WhatsApp/email OTP, Active Directory, SAML, voucher redemption, and the payment method itself, which carries the purchasable plan groups and their prices.
When you would open it. Turning on a sign-in option for the purchase flow, or — most often — setting up or editing the payment method's plan groups, zone scoping and pricing.
Before it has anything on it. The payment method needs a payment gateway connector and at least one profile to price a plan against; the OAuth-style methods (Google, Microsoft Entra, SAML) need their own connector configured under Connectors first.
Needs the view-buy-panel-login-method permission.
Configuration
/admin/buy-panel/config
The buy panel configurations — one per URL slug (yourtenant.example/buy/{slug}), each running a journey. This is the paid-access panel's equivalent of a captive portal zone, but keyed by URL path rather than SSID or controller.
When you would open it. Publishing a new purchase page at its own address and wiring it to a journey, or checking which configs are active.
Before it has anything on it. A published buy panel journey to assign — a config with none is inert.
Needs the view-buy-panel-designer permission.
Guest Accounts
/admin/buy-panel/user
Accounts created specifically through buy panel purchases — a separate table from the general Accounts › Users list, tracked by login source, status and contact details.
When you would open it. Looking up or removing a paying guest's account. This page only covers buy-panel-originated accounts, not vouchers or general captive-portal users, which live under Accounts.
Before it has anything on it. At least one completed buy panel registration or purchase for there to be anything listed.
Needs the view-buy-panel-user permission.
Portals
Media Library
/admin/portals/media
One shared media library — images, video and fonts — behind three separate stores: captive portal, WiFi Enterprise and buy panel, switched by tab.
When you would open it. Uploading assets before wiring them into a portal template, deleting stale files, or approving an image for social-share (OG) previews.
Before it has anything on it. At least one of the three underlying view permissions (captive portal, WiFi Enterprise or buy panel templates) — with none the page aborts with a 403 instead of showing an empty library.
One page, three stores: each tab keeps its own table and storage prefix — an asset uploaded under Buy Panel never shows up in the Captive Portal tab, even though the upload rules (WebP conversion, 10 MB cap, blocked extensions) are identical across all three.
Needs any of view-portal-templates, view-enterprise-templates, view-buy-panel-designer.
Translations
/admin/portals/translations
Automatic translation of the captive portal, WiFi Enterprise and buy panel pages — pick the language you write in and the languages guests should get, and every published page is translated by the tenant's AI model. A per-page editor lists each string with its translations so any line can be corrected by hand; hand-written lines are never overwritten.
When you would open it. Serving the same portal to guests in several languages without maintaining one template per language, or fixing a wording the model got wrong.
Before it has anything on it. Automatic translation switched on here (it is off for every tenant until then), a working AI credential (the tenant's own key or the platform key on System › Settings › A.I Model) with monthly allowance left, and a guest device that asks for one of the chosen languages — the captive portal uses the language the guest picked on the portal, the enterprise and buy panel pages use the browser's Accept-Language.
Translated at publish time, not per visit: publishing a page queues one job per new string and rebuilds a stored copy of the page per language; guests are served that copy only when it matches the page currently published, so an edited page falls back to the original until its translation catches up. Blank message-template translations are filled in the same way when a template is saved. Synchroweb can switch the feature off platform-wide.
Needs the view-portal-translations permission.
This list is read from the admin menu itself, so it cannot fall behind it.