Webhooks & API overview

What you'll need

• An endpoint on your side ready to receive a POST request (for webhooks) or your App Secret Key (for API access)

Steps

1. MyWiFi offers two different ways to integrate programmatically, and they solve different problems: outbound webhooks (MyWiFi sends data to a URL you provide, when something happens) and a real API (you call MyWiFi to read or manage account data on demand). See Get your API key for the API — the rest of this article covers webhooks.
2. There are two separate places you can set up a webhook, and they behave a little differently:

• Apps > Others > Webhooks — a standalone connection you can wire into the older Automations system. You provide a URL; guest data (name, email, phone, visit count, social network, location/campaign) POSTs there when an automation triggers. This connection is not cryptographically signed.
• A Journey Builder webhook step — see Add a tag or webhook step to a journey. This one is signed, with an X-MyWiFi-Signature header your endpoint can verify.

1. Both kinds of webhook are checked against basic outbound-safety rules before sending, and carry an idempotency key header so you can safely de-duplicate retries on your end.
2. If you need to verify a request genuinely came from MyWiFi, use a Journey Builder webhook step, not the standalone Apps webhook — only the Journey step includes a verifiable signature today.

Best practice: if you're building something that needs to trust the sender, always use the Journey Builder webhook step — the standalone Apps webhook is fine for simple data forwarding where authenticity verification isn't a concern. If you need to pull data or make changes on demand instead of waiting for an event, that's what the API is for, not webhooks.

Related articles

• Get your API key
• Connect a CRM or marketing app
• Set up threshold alerts