Setting up a site

A tenant from empty to a working guest portal, in the order the pieces depend on each other.

Before you start

The tenant itself has to already exist — Synchroweb creates it and assigns it a licence key before you can do anything as its admin. Sign in as an admin with the relevant permissions for that tenant, and have the controller's own connection details ready before you start: the vendor, its management IP, the shared secret you intend to use on both sides, and for some vendors an API key or admin credentials. It's also worth knowing the tenant's device quota (visible under the licence) before you start adding hardware, since registering a controller past that limit is refused outright.

1. Register the controller

This is the first real step, because nothing downstream works without it — it's what Kiwire uses to work out which tenant, and later which zone, a guest's session belongs to. On the device controllers page, add a record with a unique ID (the value the NAS itself will present, sometimes called the nasid), the vendor, a shared secret that matches what you configure on the controller's own side, and a monitoring method if you want Kiwire to track whether it's reachable. Some vendors need extra fields — SNMP community and version, a UniFi API key and site ID, a non-default CoA port. If you're bringing in an existing estate of controllers rather than adding one at a time, a CSV import sits alongside the normal form for that.

2. Map the zones

A zone groups guest traffic by SSID, VLAN or IP range and carries the policy that applies once a guest lands in it — a simultaneous-connection cap, a priority used to break ties when more than one zone's rules could match the same session, and (once you get to steps 3 and 5) the journey and any forced profile it runs. If you're defining more than one zone, priority matters: a broad, catch-all zone sitting at the same or a higher priority than a more specific one will swallow traffic that was meant for the specific zone, and the zones page actively flags this kind of shadowing when it happens. A zone with no journey attached yet is a normal intermediate state — it just doesn't show a guest anything until the next step.

3. Design the portal and journey

Build or duplicate a portal template in the designer, then build a journey that uses it — a journey is what actually ties a template, a language and config, and a post-login destination together into a flow a guest can go through. A journey has to be published before it does anything; a draft journey with nothing pointed at it is fine mid-build, but it won't serve any guest traffic. Once it's published, go back to the zone from step 2 and set its journey to this one — that's the connection that makes the zone actually show a guest a page instead of nothing.

4. Choose login methods

Turn on whichever ways of signing in this site should offer: a registered Kiwire account, a voucher code, SMS, WhatsApp or email OTP, social login, QR login, sponsored or public self-signup, paid access, or an enterprise identity source such as Active Directory, LDAP, SAML, Okta or Microsoft Entra ID. Anything beyond the built-in registered-account method needs its own connector set up first — Google, Microsoft, AD, WhatsApp or SAML each need their connector configured under Connectors before that method's own setup form has anything to select. Enabling a method here makes it available to journeys; it's still the journey (step 3) that decides which of the enabled methods actually get offered to a guest in this particular flow.

5. Set the profile

A profile is what sets the bandwidth cap, data quota, session time and idle timeout a guest gets, and every account, voucher batch or top-up code needs one attached. It's worth doing this before or alongside step 4, since the account, voucher and top-up creation forms elsewhere in the admin pull their profile choice from whatever profiles already exist — an empty list here means an empty dropdown everywhere else. If this site needs to force every guest onto one particular plan regardless of what they were assigned elsewhere, that's the zone's forced-profile setting from step 2, pointed at the profile you create here.

6. Simulate, then go live

Before pointing real hardware at the finished setup, there are two ways to check it without depending on production traffic. The designer's simulate option previews a template and journey on its own, without a NAS in the loop at all. Separately, the controller test tool opens a live capture window that shows exactly what parameters your actual controller sends the moment a guest hits the portal, so you can confirm it's sending what Kiwire expects — nasid, SSID, MAC, IP — before trusting it with real guests. Once the controller, zone, journey, login methods and profile are all wired together and a live capture looks right, the site is ready.