Skip to main contentSkip to search
Skip to main content

Archie Captive Portal Integration

IronWiFi validates Archie member WiFi logins in real time by calling the Archie REST API at each captive portal login attempt. There is no account sync — the captive portal asks Archie whether the member exists and whether their membership is currently active, and grants or denies WiFi based on the response. Archie remains the source of truth for members and plans.

How It Works​

  1. A member connects to the WiFi SSID and is redirected to your IronWiFi captive portal.
  2. The member submits their Archie email and password on the splash page.
  3. IronWiFi POSTs those credentials to the Archie API endpoint you configured on the captive portal's REST API authentication provider, passing your Archie API token as a Bearer header.
  4. Archie validates the credentials and the member's active membership, then returns 
    2xx
    to allow the session or 
    4xx
    to reject it.
  5. IronWiFi grants or denies the WiFi session based on the response.

The request and response contract is described in External Authentication via REST API.

Prerequisites​

  • An IronWiFi account with a captive portal already created. See Captive Portals.
  • An Archie account with admin access and the ability to issue an API key.
  • A walled garden on your captive portal that allows the Archie API hostname (see Walled Garden below).

Setup​

In Archie​

  1. Log in to your Archie admin panel.
  2. Go to Settings > API & Integrations and create or retrieve:
    • An API Key (used as the Bearer token).
    • Your Workspace ID, which is required in the Archie API endpoint URL.
  3. Store the API key securely — you will paste it into IronWiFi next.

In IronWiFi​

  1. Open the IronWiFi Console and go to Captive Portals.
  2. Select the captive portal you want members to authenticate against.
  3. Go to Authentication Providers > Add and choose REST API.
  4. Configure the provider:
    • Endpoint URL: The Archie endpoint for your workspace that validates the captive portal credential payload.
    • Bearer Token: The Archie API key from the previous section.
  5. Save the provider. For field-by-field details, see the REST API provider configuration reference.
  6. Make sure the REST API provider is enabled on the captive portal's login page.

Walled Garden​

Add the Archie API hostname to the captive portal's walled garden so the provider endpoint is reachable before the user is authenticated:

See Walled Garden for how to edit the list.

Testing​

  1. Connect a test device to the SSID and wait for the captive portal to load.
  2. Log in with a known-active Archie member — you should be granted WiFi.
  3. Try a paused or cancelled member — the captive portal should show an authentication failure.
  4. In the IronWiFi Console, check the captive portal session log to confirm the request hit the Archie API and returned the expected 
    2xx
    or 
    4xx
    .

Troubleshooting​

  • 401/403 from Archie — the API key is missing, wrong, or lacks permission. Regenerate it in Archie and re-paste into the REST API provider.
  • Request never reaches Archie — the Archie hostname is missing from the walled garden. Add it and retest.
  • Active members are rejected — confirm the Workspace ID in the endpoint URL is correct and the member's plan is currently active in Archie.
  • Previously working logins suddenly fail — the Archie API key may have been rotated. Issue a new one and update the provider.

Was this page helpful?