WISPGate Integration Guide
System Connectors
Resource Page / Integration Guide

Integration Guide.

A premium resource page that explains how WISPGate connects to external systems and how teams should implement them.

WISPGate provides deep, structured implementations for your hardware and software stack. This guide catalog details supported use cases, required fields, verification logic, and step-by-step deployment paths for every connector.

3
Integration Domains
1
Inner Page Template
6
Implementation Sections
∞
Future Connectors
Navigation

Guide Sections

01. Guide landing experience 02. Integration inner page 03. Implementation flow 04. Readiness checklist
WISPGate
Network & AAA
Payments
Messaging
Monitoring
Customer Ops

Guide landing page

This is the outer resource page that lists integration families, highlights business outcomes, and routes users into specific implementation guides.

Landing Overview Inner Page Template Implementation Flow Checklist
Page 01 / Integration Guide Landing

A structured entry point into the WISPGate ecosystem.

The landing page should group integrations by operational domain, expose common use cases, and help users quickly understand where each connector fits in the platform: authentication, subscriber sync, payments, notifications, monitoring, dispatch, or accounting.

Landing Resource Layout
N

Network & AAA

Routers, controllers, OLTs, ACS platforms, QoS engines, and subscriber authentication systems.

P

Payments & Finance

Gateways, mobile money, accounting tools, print offices, and reconciliation-focused integrations.

M

Messaging & Support

WhatsApp, SMS, calendar, maps, and communication providers for customer and team workflows.

O

Operations & Monitoring

Zabbix, PRTG, dispatch workflows, external events, and integrations used for operational awareness.

Landing section 01

Featured integration cards

Highlight strategic connectors first: MikroTik, UISP, Calix, SmartOLT, Stripe, QuickBooks, WhatsApp, Zabbix.

Landing section 02

Use-case grouping

Group by “Subscriber Auth,” “Billing Automation,” “Field Communication,” and “Network Monitoring.”

Landing section 03

Guide metadata

Show each integration’s type, deployment complexity, prerequisites, and supported use cases directly on the card.

Landing page user journey

1

Browse domain

User enters from resources and chooses network, payments, messaging, or monitoring.

→
2

Select integration

User sees a strategic summary, tags, and likely use cases before opening the guide.

→
3

Read implementation page

User gets the actual setup path, prerequisites, fields, flows, and troubleshooting context.

Page 02 / Inner Integration Page

Template example: MikroTik RADIUS & service enforcement integration.

This inner page is the deep guide your users, implementers, and internal team actually need. It explains scope, prerequisites, supported flows, required fields, common misconfigurations, and verification logic.

Inner Page Template / Example
Connector overview

What this integration does

Connects WISPGate to MikroTik for subscriber authentication, service activation, bandwidth policies, and account-state-driven enforcement.

Supported use cases

Where it is used

PPPoE, Hotspot, DHCP environments, suspended account policy handling, package bandwidth enforcement, and session control.

Complexity

Implementation profile

Medium. Straightforward when RADIUS and address plans are clean; painful when your network is badly structured.

Overview
Prerequisites
Fields
Troubleshooting

Prerequisites

  • MikroTik NAS reachable from the WISPGate RADIUS service
  • Shared secret defined consistently on both sides
  • Correct service model in WISPGate: subscriber, plan, package, and policy mapping
  • Clean understanding of whether enforcement is done by profile, queue, or reply attributes
Required fields
Optional

Key configuration fields

  • NAS IP / Router Identifier
  • Shared Secret
  • Authentication Method
  • Speed / Queue Policy Mapping
  • Suspension / Grace-State Handling
  • Session Timeout / Interim Update Profile

Implementation flow

A

Create NAS record

Register MikroTik router in WISPGate with shared secret and access parameters.

→
B

Bind service policy

Map package logic to RADIUS replies, queues, or rate limits used by the router.

→
C

Test subscriber auth

Verify access-accept, profile assignment, session creation, and suspension handling.

# Example configuration notes Integration Type: MikroTik / RADIUS Auth Flow: PPPoE → Access-Request → WISPGate policy engine Required Reply Attributes: Mikrotik-Rate-Limit, Framed-IP-Address Suspension Logic: Throttle or Reject based on billing policy Verification Result: Access-Accept returned with expected package profile

Common failure points

  • Wrong shared secret or router IP causes silent auth failure.
  • Package definitions do not match router-side enforcement expectations.
  • Suspension logic is configured in billing but not reflected in network policy.
  • Operators confuse customer package speed with raw router queue definitions.
01

Validation block

Show auth test status, policy test status, suspension state, and live session presence.

02

Related resources

Link to billing policies, package setup, subscriber model, and troubleshooting docs.

03

Version notes

Track changes in supported attributes, enforcement models, or compatibility assumptions.

Page 03 / Readiness & Troubleshooting

Implementation readiness and failure prevention.

Good guides don’t stop at setup fields. They help users avoid bad assumptions before deployment. This section should exist on the guide page or as a reusable component on every inner integration page.

Checklist & QA
Pre-deployment

Readiness checklist

  • Define what operational outcome this integration must produce
  • Verify network/service model assumptions before touching settings
  • Confirm credentials, IP reachability, webhooks, or callback requirements
  • Document rollback plan if integration changes live subscriber behavior
Post-deployment

Verification checklist

  • Run at least one happy-path transaction
  • Run one failure-path test and confirm the alert or fallback behavior
  • Verify logging, audit trail, and event traceability
  • Confirm business teams can actually see the result in the right record views
Troubleshooting

Guide behavior

  • Surface common errors before users open support tickets
  • Provide expected request/response or signal examples where relevant
  • Include “what success looks like” in plain operational language
  • Explain edge cases, not just the clean demo path