WiFi Analytics API Integration: REST Endpoints & Webhooks

Key Takeaways: WiFi analytics APIs turn guest WiFi data into programmable infrastructure. MyWiFi Networks publishes 33 REST API endpoints covering locations, guests, sessions, campaigns, and analytics — available on MSP and Enterprise plans. Webhooks push real-time events (new guest, session end, campaign delivery) to any HTTP endpoint, enabling integrations with CRMs, data warehouses, and custom dashboards without polling. API-first resellers command higher contract values because they can deliver custom integrations that lock-in clients. This guide covers authentication, key endpoints, webhook events, rate limits, and production integration patterns.

WiFi analytics data is only as valuable as the systems it connects to. A dashboard is useful. An API that feeds guest data into a client's CRM, triggers workflows in their marketing automation platform, and populates their business intelligence tools is transformative.

According to a 2025 Postman State of the API Report, 89% of enterprise software decisions now require API availability. For WiFi marketing resellers, this means the question from sophisticated clients is no longer "do you have analytics?" but "can your analytics feed into our existing stack?"

MyWiFi Networks publishes 33 REST API endpoints and a webhook system that makes WiFi guest data programmable. This guide covers the technical integration layer for resellers and developers building on that API.

---

API authentication

MyWiFi's API uses token-based authentication. API access is available on MSP and Enterprise plans.

Obtaining API credentials

API credentials are generated in the MyWiFi dashboard under Settings → API. Each API key pair consists of:

• •API Key (public identifier)
• •API Secret (private authentication token)

API keys are scoped to the reseller account. All locations, guests, and campaigns under the account are accessible with a single key pair. Sub-user API keys can be scoped to specific locations for client-facing integrations.

Authentication method

All API requests require the API key in the request header:

Authorization: Bearer {api_secret}
X-API-Key: {api_key}

Every request must be made over HTTPS. HTTP requests are rejected. The API base URL is https://api.mywifi.io/v2/.

Rate limits

The API enforces rate limits to protect platform stability:

Rate limit headers are returned with every response:

X-RateLimit-Limit: 60
X-RateLimit-Remaining: 47
X-RateLimit-Reset: 1711382400

When the limit is exceeded, the API returns HTTP 429 with a Retry-After header. Implement exponential backoff in production integrations.

---

Core API endpoints

The 33 published endpoints are organized into six resource groups: Locations, Guests, Sessions, Campaigns, Analytics, and System.

Locations endpoints

Locations represent physical venues. Each location has associated access points, portals, and guest data.

GET /v2/locations — List all locations under the account. Supports pagination (?page=1&per_page=50), filtering by status (?status=active), and search (?search=downtown).

GET /v2/locations/{id} — Get a single location with full detail: address, timezone, AP count, active guest count, portal configuration, and creation date.

GET /v2/locations/{id}/stats — Location-level statistics: total guests, new vs. returning ratio, average dwell time, peak hours, and capture rate. Accepts date range parameters (?from=2026-01-01&to=2026-03-25).

Guests endpoints

Guests are the core data asset. Each guest record contains the profile data captured through the captive portal plus behavioral data from RADIUS session accounting.

GET /v2/guests — List guests across all locations. Supports pagination, date range filtering, and field selection (?fields=email,name,visits,last_seen).

GET /v2/guests/{id} — Full guest profile: name, email, phone, social profiles, device type, OS, visit history, total sessions, average dwell time, first seen date, last seen date, and custom fields.

GET /v2/guests/search — Search guests by email, phone, name, or custom field. Returns matching guest records with relevance scoring.

GET /v2/locations/{id}/guests — Guests for a specific location. The most commonly used endpoint for location-scoped integrations. Supports filtering by date range, visit count, and capture method.

POST /v2/guests/{id}/tags — Add tags to a guest record. Tags enable segmentation for campaigns and CRM sync.

Sessions endpoints

Sessions represent individual WiFi connections. Each session links a guest to a location with timestamped behavioral data.

GET /v2/sessions — List sessions with filters: location, date range, minimum duration, device type.

GET /v2/guests/{id}/sessions — All sessions for a specific guest. Returns the complete visit history with per-session metrics (duration, bandwidth, AP identifier, authentication method).

GET /v2/locations/{id}/sessions — Sessions for a specific location. The primary data feed for building visit analytics, occupancy tracking, and dwell time reports.

Campaigns endpoints

Campaigns represent marketing automations (email, SMS, webhook triggers).

GET /v2/campaigns — List campaigns with status, type, and performance metrics.

GET /v2/campaigns/{id}/stats — Campaign performance: sent count, delivered, opened, clicked, bounced, unsubscribed. For webhook campaigns: delivery count, response codes, retry count.

POST /v2/campaigns — Create a new campaign programmatically. Accepts campaign type, trigger conditions, audience filters, content template, and schedule.

Analytics endpoints

Analytics endpoints return aggregated data optimized for dashboard consumption.

GET /v2/analytics/overview — Account-wide metrics: total guests, active locations, sessions today, new guests this week, capture rate trend.

GET /v2/analytics/traffic — Hourly/daily/weekly traffic data for charting. Returns time-series arrays of connection counts, unique visitors, and new captures.

GET /v2/analytics/demographics — Guest demographic breakdown: device type distribution, OS distribution, gender (from social login), age range, top email domains.

GET /v2/analytics/heatmap — Zone-level traffic data based on AP-to-zone mapping. Returns per-zone visitor counts and dwell times for generating spatial heatmaps.

GET /v2/analytics/retention — Cohort retention data: what percentage of guests captured in week N returned in weeks N+1 through N+12.

---

Webhook events

Webhooks push real-time events to your HTTP endpoint as they occur. No polling required. Webhooks are configured per-location in the MyWiFi dashboard under Location → Integrations → Webhooks.

Available webhook events

Webhook payload format

All webhook payloads are JSON with a standard envelope:

{
  "event": "guest.new",
  "timestamp": "2026-03-25T14:30:00Z",
  "location_id": "loc_abc123",
  "data": {
    "guest_id": "gst_xyz789",
    "email": "guest@example.com",
    "name": "Jane Smith",
    "device": "iPhone 16",
    "auth_method": "whatsapp",
    "session": {
      "session_id": "sess_001",
      "ap_mac": "AA:BB:CC:DD:EE:FF",
      "started_at": "2026-03-25T14:29:45Z"
    }
  }
}

Webhook security

Each webhook includes a signature header (X-MyWiFi-Signature) computed as HMAC-SHA256 of the payload using your webhook secret. Always verify this signature before processing the payload to prevent spoofing.

Retry policy

Failed webhook deliveries (non-2xx response or timeout) are retried with exponential backoff: 1 minute, 5 minutes, 30 minutes, 2 hours, 12 hours. After 5 failed attempts, the webhook is marked as failing and an alert is sent to the account owner.

---

Integration patterns

Pattern 1: CRM sync

The most common integration pushes guest data from MyWiFi into a CRM (HubSpot, Salesforce, Pipedrive).

Implementation: Configure a guest.new webhook pointing to your middleware (or directly to the CRM's API if it accepts webhooks). Map MyWiFi guest fields to CRM contact fields. Use guest.returning events to update the "last visit" field and increment visit count.

HubSpot integration example: The guest.new webhook triggers a HubSpot Contact creation via HubSpot's Contacts API. Custom properties store WiFi-specific data (visit_count, average_dwell_time, capture_location). HubSpot workflows then segment WiFi-captured contacts for email nurture sequences.

MyWiFi's MSP plan includes native HubSpot and Zapier integrations that handle this mapping without custom code.

Pattern 2: Data warehouse feed

For clients who want WiFi analytics in their existing BI stack (Looker, Tableau, Power BI), the API feeds a data warehouse.

Implementation: A scheduled job (cron, Airflow, or serverless function) calls GET /v2/locations/{id}/sessions with a date range filter, fetching new sessions since the last sync. Session data is written to the warehouse (BigQuery, Snowflake, Redshift). BI tools query the warehouse for custom reporting.

Pattern 3: Real-time occupancy

Some clients want real-time occupancy displays — "Currently 47 guests on WiFi" shown on a lobby screen or website widget.

Implementation: Use session.start and session.end webhooks to maintain a real-time counter. Each session.start increments the count; each session.end decrements it. The counter drives a display widget via WebSocket or server-sent events.

Pattern 4: Marketing automation orchestration

Advanced resellers build cross-channel automation that spans WiFi events and external marketing tools.

Implementation: The guest.new webhook triggers a workflow in n8n, Make, or Zapier. The workflow checks the guest's email against the client's existing customer database. If the guest is a known customer, send a "welcome back" offer via the client's email platform. If new, add to a first-visit nurture sequence. If returning after 30+ days of inactivity, trigger a win-back campaign.

Pattern 5: Multi-location aggregation

Enterprise resellers managing 50+ locations need aggregated views that the per-location dashboard cannot provide.

Implementation: Use GET /v2/analytics/overview with location grouping to build a custom multi-location dashboard. Combine with GET /v2/analytics/traffic per location for comparative analysis. Present in a custom portal built with the reseller's branding.

---

Error handling

The API returns standard HTTP status codes:

Error responses include a JSON body with a human-readable message and error code:

{
  "error": {
    "code": "RATE_LIMIT_EXCEEDED",
    "message": "Rate limit of 60 requests per minute exceeded. Retry after 23 seconds.",
    "retry_after": 23
  }
}

---

Pagination

All list endpoints use cursor-based pagination for consistent performance:

GET /v2/guests?per_page=50&cursor=eyJpZCI6MTIzNH0

Response includes pagination metadata:

{
  "data": [...],
  "pagination": {
    "per_page": 50,
    "total": 12847,
    "next_cursor": "eyJpZCI6MTI4NH0",
    "has_more": true
  }
}

Always use cursor-based pagination for large data sets. Offset-based pagination (?page=500) degrades performance on tables with millions of rows.

---

Building a production integration

Checklist for production readiness

1. •Verify webhook signatures. Never process unverified webhook payloads.
2. •Implement idempotency. Webhooks may be delivered more than once. Use the event ID for deduplication.
3. •Handle rate limits gracefully. Implement exponential backoff with jitter.
4. •Use date range filters. Never fetch the full guest list on every sync. Use ?from= parameters for incremental fetches.
5. •Monitor webhook delivery. Set up alerting for webhook failures. MyWiFi's dashboard shows delivery status per webhook endpoint.
6. •Cache location and AP data. These change infrequently. Cache them locally and refresh daily rather than fetching per-request.
7. •Log API responses. Store raw API responses for debugging. Especially useful when data discrepancies arise between the MyWiFi dashboard and the integrated system.

SDKs and libraries

MyWiFi provides API documentation at mywifinetworks.com/apidocs. Community SDKs exist for JavaScript/Node.js and Python. For production integrations, the REST API with your own HTTP client is recommended for full control over retry logic and error handling.

---

API-driven competitive advantage for resellers

Resellers who use the API create deeper client integrations that competitors cannot easily replicate. According to a 2025 SaaS Capital survey, SaaS products with API integrations show 31% lower churn than dashboard-only products.

The API transforms your service from "here's a WiFi dashboard" to "WiFi data flows into every system your client already uses." That integration depth creates switching costs — a client would need to rebuild all their data connections to move to a competitor.

For MSP resellers, the API also enables white-label dashboards. Build a custom analytics interface using MyWiFi's API as the data backend, presented under your own brand on your own domain. The client never sees MyWiFi — they see your platform powered by your white-label deployment.

---

FAQ

Which MyWiFi plans include API access? The developer API with full endpoint access is available on MSP ($999/mo) and Enterprise (custom) plans. Webhooks are available on Agency ($499/mo) plans and above.

How much historical data is available through the API? The API provides access to all historical data stored in the account. There is no time-based data expiration through the API. Data retention follows the account's data retention policy.

Can I use the API to create and manage captive portals? The current API (v2) covers data retrieval, guest management, and campaign management. Portal creation and design management are planned for a future API version. Currently, portal design is managed through the dashboard.

What is the difference between the API and Zapier integration? Zapier provides pre-built connectors for common workflows (new guest → add to Mailchimp, session end → update HubSpot). The API provides full programmatic access for custom integrations. Use Zapier for standard workflows and the API for custom builds.

How do I test webhooks during development? Use a webhook testing service (RequestBin, Hookdeck, or ngrok tunnel to localhost) as your webhook URL during development. MyWiFi's dashboard includes a "Test" button that sends a sample payload to your configured endpoint.

Are there rate limit exceptions for data migration or initial sync? Contact support before running a large initial data sync. Enterprise plans can request temporary rate limit increases for migration scenarios.