Webhook automation for WiFi events: real-time guest triggers

Key takeaways: Webhooks deliver WiFi event data to external systems in real time — within seconds of a guest connecting, authenticating, or disconnecting. Unlike API polling (where you periodically check for new data), webhooks push data the moment something happens. Practical applications: instant CRM updates, real-time Slack notifications for VIP guests, POS-triggered offers based on WiFi visit data, and multi-system workflows via Zapier or n8n. Webhooks are available on Agency plans and above.

Webhook payloads and event types referenced in this article are illustrative. Actual payload structure depends on the platform. Refer to MyWiFi's documentation for current webhook specifications.

The built-in marketing automation in a WiFi marketing platform covers the standard use cases: welcome emails, return visit reminders, birthday campaigns. That's enough for most deployments.

But some clients — the enterprise accounts, the MSPs, the technical agencies — want WiFi events to trigger actions in external systems. A new guest login should create a record in HubSpot. A VIP guest's arrival should notify the general manager via Slack. A guest disconnection should trigger a satisfaction survey in Typeform.

That's what webhooks are for. They're the plumbing that connects WiFi events to everything else.

---

What webhooks are (60-second primer)

A webhook is an HTTP POST request that a system sends automatically when an event occurs. Instead of you asking the system "did anything happen?" every 5 minutes (polling), the system tells you immediately when something happens (pushing).

The analogy: Polling is checking your mailbox every hour. A webhook is the mailman ringing your doorbell.

How it works:

1. •You configure a webhook URL in the WiFi marketing platform (e.g., https://yourserver.com/wifi-webhook)
2. •You select which events should trigger the webhook (guest authenticated, guest disconnected, etc.)
3. •When the event occurs, the platform sends an HTTP POST to your URL with a JSON payload containing the event data
4. •Your server receives the payload and takes action (creates a CRM record, sends a Slack message, updates a database, etc.)

---

WiFi events that can trigger webhooks

The most commonly used webhook events for custom automation are guest authenticated (new data capture) and inactivity threshold (retention triggers).

---

10 webhook automation recipes

Recipe 1: Instant CRM contact creation

Event: Guest authenticated Action: Create contact in HubSpot/Salesforce/Pipedrive

Flow:

WiFi platform → webhook POST → middleware (Zapier/n8n/custom) → CRM API → contact created

Payload example:

{
  "event": "guest_authenticated",
  "contact": {
    "email": "jane@example.com",
    "name": "Jane Smith",
    "login_method": "email",
    "location": "Downtown Cafe",
    "timestamp": "2026-03-26T14:32:07Z"
  }
}

Middleware logic: Check if contact exists in CRM by email. If yes, update with latest visit. If no, create new contact with source tag "WiFi Guest."

Recipe 2: VIP arrival notification

Event: Return visit detected (for contacts tagged as "VIP") Action: Send Slack message to venue general manager

Flow:

WiFi platform → webhook POST → filter (is VIP?) → Slack API → message sent

Slack message: "VIP alert: Jane Smith just connected to WiFi at Downtown Cafe. Visit #12. Last visit: March 19."

This is particularly valuable for hospitality clients (hotels, high-end restaurants, private clubs) where personalized greeting of frequent guests drives satisfaction and retention.

Recipe 3: Post-visit survey

Event: Guest disconnected (after 15+ minute session) Action: Send survey link via email or SMS (through external platform)

Flow:

WiFi platform → webhook POST (disconnect) → delay 2 hours → survey platform API → survey invitation sent

Why the delay: Sending a survey the moment someone disconnects from WiFi feels invasive. A 2-hour delay feels natural — like a follow-up from a real person.

Recipe 4: POS cross-reference

Event: Guest authenticated Action: Check POS system for recent transaction from the same email

Flow:

WiFi platform → webhook POST → POS API query (email match) → result
  If purchased: tag contact as "buyer" in WiFi platform
  If no purchase: trigger promotional email with offer

This cross-reference lets you segment WiFi guests into buyers and non-buyers, enabling different automation tracks for each.

Recipe 5: Loyalty point accrual

Event: Guest authenticated (return visit) Action: Add loyalty points in external loyalty system

Flow:

WiFi platform → webhook POST → loyalty system API → add points → confirmation email to guest

Every WiFi connection earns a loyalty point. No punch cards. No app. The loyalty tracking is invisible to the guest — they just connect to WiFi as usual and accumulate points automatically.

Recipe 6: Staff training trigger

Event: Negative review detected (via review platform webhook) Action: Cross-reference with WiFi visit data to identify the visit

Flow:

Review platform → webhook POST (1-star review) → match reviewer email to WiFi contact → pull visit data (date, duration, location zone) → send Slack alert to manager with context

When a bad review comes in, the manager gets: "1-star review from Jane Smith. She visited on March 22, spent 23 minutes (short for her — average is 55 min), connected to Patio AP. Previous visits: 8 (was a regular). Something went wrong on March 22."

Recipe 7: Multi-location aggregator

Event: Guest authenticated (any location) Action: Update a central analytics database

Flow:

WiFi platform → webhook POST → analytics database INSERT → dashboard updates

For enterprise clients with 50+ locations, this builds a real-time analytics database outside the WiFi platform that feeds custom dashboards, BI tools, and executive reports.

Recipe 8: Competitor monitoring

Event: Guest authenticated (first time) Action: Check if the email appears in competitor databases (via data enrichment API)

Flow:

WiFi platform → webhook POST → data enrichment API (Clearbit, FullContact) → company and role data → tag contact in WiFi platform

If the first-time guest works at a competitor or a vendor, tag them differently. Don't send them promotional emails — send them partnership information. Or flag them for manual review.

Recipe 9: Automated reporting

Event: Time-based (daily, weekly, monthly) Action: Generate and email a formatted report

Flow:

Cron trigger → WiFi API call (analytics data) → report template engine → email delivery → client inbox

The webhook here is reversed — the trigger is time-based, and the action pulls data from the WiFi API. But the concept is the same: automation replaces manual report generation.

Recipe 10: Emergency guest notification

Event: Manual trigger (emergency button, system alert) Action: Broadcast message to all currently connected guests

Flow:

Emergency trigger → WiFi platform API (list connected devices) → SMS/push notification to connected guests → "Emergency notice: Building evacuation in progress. Exit via nearest marked exit."

This is an edge case, but it demonstrates the power of real-time WiFi data: you know who's in the building right now, and you can reach them instantly.

---

Building reliable webhook receivers

Essential practices

1. Respond immediately. Your webhook endpoint should return a 200 OK within 1–2 seconds. Do the heavy processing asynchronously (queue the payload, process later). If your endpoint takes too long, the sender may timeout and retry, causing duplicate deliveries.

2. Handle duplicates. Include idempotency logic. If you receive the same webhook event twice (which happens due to retries), your processing should produce the same result. Use the event ID or a hash of the payload to detect duplicates.

3. Validate the payload. Verify that the webhook came from the WiFi platform, not an attacker. Use HMAC signature verification if the platform supports it. At minimum, validate the payload structure before processing.

4. Log everything. Store the raw webhook payload before processing. When something goes wrong (and it will), you'll need the raw data to debug.

5. Build retry logic. If your webhook processing fails (CRM API is down, database timeout), queue the payload for retry. Don't lose data because of a transient failure.

Hosting options

For most resellers, Zapier or n8n handles webhook processing without writing custom code. For high-volume or complex integrations, AWS Lambda or a dedicated server provides more control.

---

Webhooks vs. Zapier: when to use which

MyWiFi supports both Zapier integration and raw webhook delivery. Here's when to use each:

Use Zapier when:

• •The destination app is in Zapier's library (HubSpot, Mailchimp, Slack, Google Sheets, etc.)
• •The logic is simple (1:1 mapping, basic filtering)
• •You don't want to manage hosting or code
• •The client's team can modify the Zap themselves

Use raw webhooks when:

• •The destination app isn't in Zapier
• •The logic is complex (conditional branching, multiple API calls, data transformation)
• •Volume is high (Zapier charges per task)
• •You need full control over retry logic and error handling
• •You're building a productized integration

---

FAQ

What happens if my webhook endpoint is down when an event fires? Most platforms retry webhook delivery 3–5 times with exponential backoff (immediate, 1 minute, 5 minutes, 30 minutes, 2 hours). If all retries fail, the event is lost. Build your endpoint for high availability, or use a queuing service (SQS, RabbitMQ) as a buffer.

Can I receive webhooks for historical events (backfill)? Webhooks are real-time only. For historical data, use the API to export past events. Webhooks are forward-looking; the API is for historical queries.

How do I test webhooks during development? Use a service like webhook.site or RequestBin to inspect incoming webhook payloads. This lets you see the exact JSON structure before building the processing logic.

Are webhooks secure? Webhooks are sent over HTTPS (encrypted in transit). The receiving endpoint should be HTTPS as well. Use HMAC signature verification to authenticate the webhook source. Never expose a webhook endpoint without authentication.

Which MyWiFi plans include webhook support? Webhooks are available on Agency ($499/month) and above. Zapier integration is available on Pro plans ($199/month) and above. MSP and Enterprise plans include full API access.

---

Resellers building webhook integrations can start a free trial on an Agency or MSP plan to access webhook configuration and test event delivery against a live portal.