API-first WiFi marketing: building custom integrations

Key takeaways: WiFi marketing platforms with APIs let resellers and SaaS developers build custom integrations that go beyond out-of-the-box features. Common integrations: real-time contact sync to CRMs (HubSpot, Salesforce), custom analytics dashboards for enterprise clients, automated provisioning for multi-location deployments, and webhook-driven workflows that trigger external systems on guest events. The API turns a WiFi marketing platform from a standalone tool into a data source that feeds an entire client tech stack. API access is typically available on MSP and Enterprise plans.

API examples in this article are conceptual. Specific endpoints and authentication methods vary by platform. See MyWiFi's API documentation for current specifications.

Most WiFi marketing resellers use the platform's built-in features: captive portal builder, email campaigns, analytics dashboard. That covers 80% of use cases. The other 20% — the enterprise clients, the MSP deployments, the SaaS integrations — require custom work.

That custom work runs through the API.

An API-first approach treats the WiFi marketing platform as a data source and automation engine, not just a dashboard. Guest data flows out to CRMs. Configuration changes flow in from provisioning scripts. Analytics feed custom reports. Everything is programmatic, scriptable, and integratable.

For resellers who serve technical clients or who want to build productized services on top of WiFi marketing, the API is the unlock.

---

What WiFi marketing APIs expose

A well-designed WiFi marketing API provides access to four categories of data and operations:

1. Contact data (read/write)

• •List all contacts for a location or account
• •Get contact details (email, name, phone, visit history, device info)
• •Create or update contacts programmatically
• •Delete contacts (GDPR compliance)
• •Export contact lists (filtered by date range, segment, location)

2. Location and device management

• •List locations and access points
• •Create new locations
• •Configure SSID settings
• •Update captive portal configurations
• •Monitor AP status (online/offline, connection count)

3. Campaign and automation management

• •List campaigns (email, SMS)
• •Trigger campaign sends
• •Get campaign analytics (sent, opened, clicked, bounced)
• •Create and modify automation workflows
• •Pause or resume automations

4. Analytics and reporting

• •Get connection statistics (total, unique, new vs. returning)
• •Get presence analytics (traffic by hour, day, week)
• •Get dwell time distributions
• •Get device type breakdowns
• •Get campaign performance metrics

---

Five custom integrations resellers build

1. Real-time CRM sync

The problem: Venue clients use HubSpot, Salesforce, or another CRM. They want WiFi-captured contacts to appear in their CRM automatically — not as a manual CSV export, not through a nightly sync, but in real time.

The solution: A webhook listener that receives guest authentication events from the WiFi platform and creates/updates contacts in the CRM.

Architecture:

Guest logs into WiFi
  → Platform fires webhook with contact data
  → Webhook listener (your service or Zapier)
  → CRM API: create or update contact
  → Contact appears in CRM within seconds

MyWiFi supports webhook integrations that fire on events like "new guest authenticated" and "guest returned." Each webhook delivers a JSON payload with the contact's email, name, location, timestamp, and other captured fields.

For HubSpot and Salesforce, the integration logic is:

1. •Receive webhook payload
2. •Search CRM for existing contact by email
3. •If found: update with latest visit data (timestamp, location)
4. •If not found: create new contact with all captured fields
5. •Apply CRM tags/labels based on WiFi segment (new visitor, regular, etc.)

Reseller value: Offering "WiFi-to-CRM sync" as a productized service. Charge $99–$299/month per client on top of the platform fee. Build it once, deploy to every CRM client.

2. Custom analytics dashboard

The problem: Enterprise clients with 20+ locations don't want to log into the WiFi platform to check analytics. They want a custom dashboard embedded in their existing BI tools (Looker, Tableau, Power BI) or a branded portal.

The solution: API calls that pull analytics data and feed it into the client's preferred visualization tool.

Data flows:

• •Daily cron job pulls connection stats per location via API
• •Data loads into a data warehouse (BigQuery, Snowflake, or a simple PostgreSQL database)
• •BI tool queries the warehouse and renders dashboards

Dashboard content for enterprise clients:

• •Locations ranked by connections per day
• •Month-over-month traffic trends per location
• •New vs. returning visitor ratios across the portfolio
• •Campaign performance comparison across locations
• •Heatmap of peak hours by location

Reseller value: White-labeled analytics dashboard as a premium add-on. Enterprise clients pay $500–$2,000/month for branded reporting that consolidates WiFi data with other data sources (POS, Google Analytics, social media).

3. Automated multi-location provisioning

The problem: An MSP onboarding a new client with 50 retail locations doesn't want to manually configure 50 locations, 50 SSIDs, and 50 captive portals through the dashboard.

The solution: A provisioning script that uses the API to create locations, configure settings, and deploy portals programmatically.

Script logic:

For each location in client_locations:
  1. Create location via API (name, address, timezone)
  2. Add access points via API (MAC addresses, model)
  3. Apply captive portal template via API (design, form fields, redirect URL)
  4. Set automation rules via API (welcome sequence, return visit triggers)
  5. Configure analytics reporting via API (schedule, recipients)
  6. Log results

A 50-location deployment that would take 2 days of manual dashboard work finishes in minutes via script.

Reseller value: Fast onboarding for large clients. Win the deal, deploy in a day. Charge a one-time setup fee ($50–$100 per location) plus the ongoing platform subscription.

4. POS data integration

The problem: A restaurant chain wants to connect WiFi visitor data with POS transaction data. The question: "Are our WiFi-captured guests spending more than non-captured guests?"

The solution: Match WiFi contact profiles with POS transactions using email address (if the POS captures email at checkout) or time-based correlation (WiFi session timestamp + POS transaction timestamp at the same location within a window).

Architecture:

WiFi platform API → Guest visit records (email, timestamp, location)
POS system API → Transaction records (email/loyalty ID, timestamp, amount, location)

Matching logic:
  If email matches: direct link
  If no email match: time-based correlation (same location, ±30 min window)

Output:
  WiFi visitors who purchased: avg transaction $42
  WiFi visitors who didn't purchase: retarget with promotion
  Non-WiFi visitors (POS-only): no retargeting possible

This integration answers the "so what" question that CFOs ask about WiFi marketing. "Guests who connected to WiFi and received our follow-up emails had a 22% higher average transaction value." That's a number that justifies the platform cost.

5. White-label mobile app integration

The problem: A reseller wants to build a branded mobile app for their clients that includes WiFi analytics alongside other business tools.

The solution: API calls embedded in the mobile app that pull real-time analytics, contact counts, and campaign stats from the WiFi platform.

App screens powered by WiFi API:

• •"Today's visitors" — Real-time connection count
• •"Contact database" — Searchable guest list with visit history
• •"Campaign performance" — Email open rates, click rates
• •"Weekly report" — Auto-generated summary with charts

Reseller value: A branded mobile app differentiates the reseller from competitors who just hand clients a dashboard login. The app becomes the reseller's product, with WiFi data as one of several integrated data sources.

---

Technical considerations

Authentication

WiFi marketing APIs typically use API key authentication (a secret key passed in the request header) or OAuth 2.0 for more granular access control. Store API keys securely — never in client-side code, version control, or unencrypted configuration files.

Rate limiting

API rate limits prevent abuse and ensure platform stability. Typical limits: 60–120 requests per minute for read operations, lower for write operations. Design integrations to batch requests when possible and cache data locally to reduce API calls.

Webhook reliability

Webhooks are fire-and-forget HTTP POST requests. If the receiving endpoint is down, the webhook payload is lost. Build webhook receivers with:

• •Retry logic (accept the webhook, queue the processing, retry on failure)
• •Idempotency (handle duplicate webhook deliveries gracefully)
• •Logging (store raw webhook payloads for debugging)

Data freshness

API data is typically near-real-time (seconds to minutes). Presence analytics may have slightly longer aggregation delays (5–15 minutes) because connection and disconnection events are batched by the AP controller.

For dashboards that need real-time updates, use webhooks (push) rather than API polling (pull).

---

When to use the API vs. built-in features

The pattern: built-in features cover standard deployments. The API unlocks enterprise, multi-location, and custom integration scenarios.

---

Building an API practice as a reseller

Who needs API integrations?

• •Enterprise clients with existing tech stacks (CRM, BI, ERP) that WiFi data needs to feed
• •MSPs deploying at scale who need automated provisioning
• •SaaS companies building WiFi marketing into their own platform
• •Agencies who want branded dashboards and white-label tools

Pricing API services

These are premium services with high margins. A reseller who can build API integrations commands significantly higher per-client revenue than one who only deploys out-of-the-box features.

Build vs. buy

Before building a custom integration, check if it already exists:

• •Zapier integration covers 1,000+ apps with no code
• •Built-in integrations cover Mailchimp, HubSpot, Salesforce, ActiveCampaign, and others
• •The API documentation may include ready-made recipes for common integrations

Only build custom when the client's requirements exceed what's available out of the box.

---

FAQ

Which MyWiFi plans include API access? API access is available on MSP ($999/month) and Enterprise (custom pricing) plans. Webhook integrations are available on Agency ($499/month) and above. Zapier integration is available on Pro plans and above.

What programming languages can I use with the API? Any language that can make HTTP requests: Python, Node.js, PHP, Ruby, Go, C#. The API returns JSON responses, which every modern language can parse natively.

Is there a sandbox/test environment? Check the API documentation for sandbox availability. When no sandbox exists, create a test location within your account and use it for development. Don't test against production locations with real guest data.

How do I handle API versioning? WiFi marketing APIs may version their endpoints (e.g., /v1/contacts, /v2/contacts). Always pin your integration to a specific API version. Subscribe to the platform's changelog or developer newsletter for deprecation notices.

Can I build integrations for my clients and resell them? Yes. Many resellers build productized integrations and charge monthly fees for maintaining them. The WiFi platform's API powers the integration; the reseller owns the custom code and the client relationship.

---

Developers and MSPs can explore the MyWiFi API documentation and start a free trial to access a test environment for building custom integrations.