Skip to content

Designers and journeys ​

Kiwire has three of them — captive portal, WiFi Enterprise and buy panel — built on one model and differing in how a journey reaches a guest.

One model, three portals ​

Each of the three portals is made of the same three things. A template is what the guest sees: a page built in the drag-and-drop (GrapesJS) designer, saved as draft work and separately published. A journey is the ordered flow the guest walks through — which template opens first, which login method the page offers, and what happens after login. A journey is stored as a graph of pages and buttons, and it too has a draft-or-published state and an active toggle.

The one model behind the three portals Three columns, one each for the captive portal, WiFi Enterprise and the buy panel. In every column a template made in the designer is referenced by a journey, which carries the login method and the flow and must be published, and the journey is attached to something that actually receives guests. Only that attachment differs: the captive portal attaches a journey to a zone, matched from the controller's redirect by SSID, VLAN, NAS ID or IP; WiFi Enterprise attaches it to a portal configuration served at /wifi/ followed by a slug, which lists the SSIDs it covers; the buy panel attaches it to a configuration served at /buy/ followed by a slug. One media library, with a separate store for each of the three, sits under all of them. Captive portalWiFi EnterpriseBuy panelTemplatedesigner output: pages, stylingTemplatedesigner output: pages, stylingTemplatedesigner output: pages, styling1 REFERENCED BY1 REFERENCED BY1 REFERENCED BYJourneylogin method + flowPUBLISHEDJourneylogin method + flowPUBLISHEDJourneylogin method + flowPUBLISHED2 ATTACHED TO2 ATTACHED TO2 ATTACHED TOZonematched from the NAS redirectby SSID, VLAN, NAS ID or IPPortal configuration/wifi/{slug}lists the SSIDs it coversConfiguration/buy/{slug}one per URL slug, no zoneMedia libraryone page, three stores — images, video and fonts for every template above
A template does nothing on its own: it only reaches a guest through a journey, and only once that journey is published and attached. The attachment is the only structural difference between the three portals — a zone matched from the controller's redirect, a WiFi Enterprise configuration at its own slug, or a buy-panel configuration at its own slug.

A template on its own does nothing, and neither does a journey: a journey is inert until it is attached to something in the world. The attachment is the part that differs between the three portals. Captive portal journeys attach to zones, WiFi Enterprise journeys attach to portal configurations reached at /wifi/{slug}, and buy panel journeys attach to configurations reached at /buy/{slug}. The sections below cover each.

All three share the Media Library — one page, three separate stores — and all three have their own Login Methods list, because the identity sources that make sense for free guest Wi-Fi, for 802.1X device enrollment and for selling access are not the same. Publish state matters at every level: the runtime only loads published, active journeys, and the enterprise runtime refuses a page whose template is not published.

Captive portal ​

Captive portal journeys attach to zones. Zones Mapping (/admin/captive-portal/zones) is where a zone is given its detection rules and the journey it runs. When a controller redirects a guest to /login/{login-config-slug}, Kiwire reads the NAS parameters (NAS ID, VLAN, SSID, client IP or IPv6, and the controller's own zone name), walks the active zones' rules in priority order and picks the first rule whose non-empty fields all match. A rule with every field blank matches everything, which makes it a catch-all rather than "no rule". If nothing matches the guest lands in no zone; if the matched zone has no published, active journey the guest falls back to the tenant's default published template instead of a flow. A journey can also name a different first page per zone, so one journey can serve several zones with different entry points.

The captive portal has four pages the other two flavours do not. Message Template (/admin/captive-portal/message-template, listed in the menu under Grow → Messages) holds the SMS, WhatsApp, email and voucher wording sent during login, and the expiry and payment reminders sent by Automatic messages — OTP codes, password resets, voucher delivery — with per-language translations; a template is only used once a login method or the forgot-password flow references it. Rules (/admin/captive-portal/rules) is a visual trigger → condition → action builder: it fires when a form is submitted, a page is visited or a login error occurs, checks conditions such as zone, guest type, time of day, day of week or a form field's value, and queues actions — push data to a webhook, push to a Google Sheet, send an SMS/email/WhatsApp notification, force a RADIUS CoA, or write a log line. Actions run in the background so a slow webhook never blocks the login, and a rule does nothing until its active toggle is on.

Placeholders. A template body is plain text or HTML with {{name}} tokens that Kiwire swaps at send time; which tokens are filled depends on the template's type and, for email, its purpose (generic or forgot-password). An email template with the generic purpose, used by the email-OTP and OAuth2-email verification mails, gets {{verification_link}}, {{username}}, {{fullname}} and {{tenant_id}} (plus {{time}} and the guest's {{device_mac}}, {{device_os}}, {{device_brand}}, {{device_class}} and {{device_model}}). One with the forgot-password purpose gets {{reset_link}}, {{username}}, {{fullname}} and {{tenant_id}}; when the forgot-password method's reset mode is "temporary password" rather than "link" it also gets {{reset_otp}} (the temporary password) and {{expires_in}} (its lifetime, e.g. "30 minutes"), and if the body never places {{reset_link}} a Reset Password button is appended below it. A WhatsApp template gets only {{link_url}}, the verification link. A voucher template is used for the printed slip from Accounts › Vouchers and gets {{voucher_code}}, {{username}}, {{password}}, {{validity}}, {{date_expiry}}, {{logo}} and {{remark}}. Engagement campaign messages fill {{fullname}}, {{username}} and {{tenant_id}}. The form's placeholder picker also lists {{password}} and {{verify_button}} for email and {{otp_code}} for SMS, but no current send path substitutes those — they are left as typed.

Bypass Devices (/admin/system/bypass-devices) is a MAC/IP whitelist pushed straight to a controller through a per-vendor driver, so a kiosk or printer never sees the login page. Kiwire keeps no copy of the list — what the page shows is read live from the controller, and a vendor without a driver is flagged as unsupported rather than offered the form.

Simulation (/admin/captive-portal/simulation) lets you exercise the real flow without a Wi-Fi client. Pick an active controller and, optionally, a zone; the page prefills the VLAN, SSID and client IP that zone's rules expect, then opens the genuine /login/{slug} entry point with those synthetic NAS parameters plus a simulation flag. The flag marks the portal session as a simulation and relaxes the framing headers so the page can render inside the admin's mobile preview.

WiFi Enterprise ​

WiFi Enterprise journeys attach to portal configurations (/admin/wifi-enterprise/portal-config). Each configuration has a slug — unique across the whole platform, not just the tenant — and is served at /wifi/{slug}; it names the journey it runs, the SSID(s) the issued device profile will join, and options such as the certificate panel, Passpoint and EAP-TTLS profiles, account and certificate expiry days. The runtime refuses the page if the configuration is inactive, has no journey, the journey is not published, or the journey has no content.

An enterprise journey ties together a template, a login method and certificate issuance: after the guest signs in, the portal generates a per-user certificate and hands back a device profile (.mobileconfig on Apple devices) that joins the SSID. Profile generation depends on the platform RADIUS certificate, which Synchroweb manages for the whole platform: if the root CA has not been generated, guests get a "Root CA is not ready" error instead of a download. The server certificate has its own expiry, and the Configuration page shows how long it has left — keep it current, since every issued profile trusts it.

Enterprise Login Methods (/admin/wifi-enterprise/login-method) offer a registered Kiwire account, Google, Microsoft Entra, Active Directory, WhatsApp and SAML. Every method except registered-account requires its matching connector under Connectors before its own form has anything to select, and those connector-backed methods also name the profile the enrolled account is created under.

Buy panel ​

Buy panel journeys attach to configurations keyed by URL slug (/admin/buy-panel/config), served at /buy/{slug}. Nothing about a zone, SSID or controller is involved: a buyer reaches the page by its address. The runtime refuses the page if the configuration is inactive or its journey is not published.

Login methods here (/admin/buy-panel/login-method) cover registered account, Google, Microsoft Entra and social login, WhatsApp and email OTP, Active Directory, SAML and voucher redemption, plus the payment method, which is where the purchasable offer lives: plan groups (each optionally scoped to particular zones), the plans within each group, and for every plan the profile it buys and its price, in the tenant's currency with its tax rate. The payment method needs a payment-gateway connector and at least one profile to price against.

Accounts created through a purchase go to their own table — Buy Panel › Guest Accounts (/admin/buy-panel/user) — separate from Accounts › Users, and are tracked by login source and status. A configuration can also be run as a hub — a shared configuration Synchroweb can set up across tenants, so one purchase flow serves several sites from one place — which suits a franchise or reseller; ask Synchroweb support if you need one.

Media ​

There is one Media Library page (/admin/portals/media) with three tabs: Captive Portal, WiFi Enterprise and Buy Panel. Each tab is a separate store with its own storage area, so an image uploaded under Buy Panel never appears in the Captive Portal designer and the other way round. The upload rules are the same everywhere — images are stored as WebP with their dimensions recorded, MP4 video and fonts are accepted, and an asset can be approved for social-share (OG) previews.

Opening the page needs at least one of the three view permissions (view-portal-templates, view-enterprise-templates or view-buy-panel-designer); with none of them it returns 403 rather than an empty library, and each tab appears only for admins holding that store's permission.

Publishing and going live ​

A template alone does nothing. The chain is: publish the template, reference it from a journey, publish the journey (and leave it active), then attach the journey — to a zone for the captive portal, to a portal configuration for WiFi Enterprise, to a slug configuration for the buy panel — and make sure that attachment is active. Break any link and the guest sees either a fallback page or a "not published" message, depending on the flavour. A draft journey with nothing attached is normal mid-build; it just carries no traffic.

To test, use the path each flavour offers. For the captive portal, Simulation opens the real login entry point with synthetic NAS parameters, so it exercises zone matching, the journey and the login methods without a client on the Wi-Fi. For WiFi Enterprise there is no simulator: open /wifi/{slug} in a browser, or join the SSID from a real device, since the useful outcome is an installed profile. For the buy panel, open /buy/{slug} — the same URL buyers will use.

Where to look: Portals: captive portal, WiFi Enterprise and buy panel.

Last updated:

Kiwire platform documentation