Webhooks

The Webhooks integration allows WAVER to send guest login information to an external system immediately after a guest connects. This makes it possible to synchronize guest data with CRMs, email platforms, spreadsheets, analytics services, automation tools, or custom applications without requiring a dedicated WAVER integration for each service.

Webhooks are configured from: Captive Portal > Connected > Advanced 


When a guest successfully connects, WAVER sends an HTTP request to the configured destination. The receiving system can store the information, update a contact, start an automation, notify staff, or pass the data to other connected applications.

Privacy notice: Webhook data may include email addresses, mobile numbers, IP and MAC addresses, custom form fields, and other guest information. Enable this feature only when the destination is authorized to receive the data and your use complies with the applicable privacy policy, consent choices, and legal requirements.

How webhooks work

WAVER supports two delivery methods:

• GET – URL parameters: Sends selected values as parameters in the destination URL using dynamic tags.

• POST – JSON format: Sends a complete, structured guest-login payload in the request body.

POST – JSON format is recommended for Zapier, Make, custom APIs, and most modern integrations. It sends the available fields in a structured format and avoids placing guest information directly in the URL.

GET is useful for simple endpoints that require only a few selected values. However, URL parameters may be stored in server, proxy, or security logs, so avoid GET when sending sensitive or personally identifiable information.

Configuring a webhook

1. Navigate to Captive Portal > Connected > Advanced.

2. Enable Webhook.

3. Select the delivery Method:

   • GET – URL parameters

   • POST – JSON format

4. Enter the receiving service's URL under Destination URL.

5. If using GET, add the required dynamic tags to the URL.

6. Enable OTP Webhook only when using a trusted custom email or SMS delivery workflow.

7. Click Save.

8. Use Test Webhook to verify the configuration.

9. Review Webhook Log to confirm that events are being delivered successfully.

GET example

https://server.example/webhook?email={{email}}&ip={{ip}}&marketing={{marketing}}

At runtime, WAVER replaces each dynamic tag with the corresponding value from the guest session.

POST – JSON payload

POST sends a structured payload based on the login method used. Depending on which information is available, it may include:

• WAVER router hostname or identity.

• Guest device IP and MAC addresses.

• Device vendor or operating-system type.

• Login method and login timestamp.

• Voucher username, email address, mobile number, or Facebook details.

• Custom portal fields, such as name, surname, or city.

• Marketing-consent status.

• Email or SMS OTP information when the OTP Webhook is enabled.

Fields that do not apply to the selected login method may be empty or unavailable.

Dynamic tags for GET webhooks

The following tags can be included in a GET destination URL:

Tag	Description
{{identity}}	Router hostname configured in the dashboard
{{ip}}	Guest device IP address
{{mac}}	Guest device MAC address
{{vendor}}	Guest device type, such as Android, Apple, Windows, or Linux
{{login_time}}	Guest login timestamp
{{login_method}}	Login method: free, voucher, email, mobile, or Facebook
{{login_data}}	Primary login value, such as a username, email address, or mobile number
{{username}}	Voucher username
{{email}}	Guest email address
{{mobile}}	Guest mobile number
{{field1}}	Custom portal field 1, such as name
{{field2}}	Custom portal field 2, such as surname
{{field3}}	Custom portal field 3, such as city
{{marketing}}	Marketing consent: 1 for accepted or 0 for not accepted
{{fb_name}}	Facebook full name, when available
{{fb_username}}	Facebook username, when available
{{fb_email}}	Facebook email address, when available
{{email_otp}}	Email OTP, when enabled
{{sms_otp}}	SMS OTP, when enabled

Dynamic tags are not required when using POST because the available information is included in the JSON request body.

Integrating WAVER with Zapier

Zapier can receive the WAVER webhook as the trigger for a Zap. The guest data can then be mapped into the actions supported by the applications connected to Zapier.

Zapier Configuration

1. In Zapier, create a new Zap.

2. Select Webhooks by Zapier as the trigger application.

3. Select Catch Hook as the trigger event.

4. Continue to the test step and copy the webhook URL generated by Zapier.

5. In WAVER, open Integrations > Webhooks.

6. Enable the webhook and select POST – JSON format.

7. Paste the Zapier webhook URL into Destination URL and click Save.

8. Click Test Webhook, or complete a test guest login, to send a sample event.

9. Return to Zapier and select Test trigger.

10. Confirm that Zapier detected the guest fields.

11. Add the required filters and actions, map the WAVER fields, and publish the Zap.
    
    

Zapier's Catch Hook trigger parses incoming data so that individual values can be mapped into later workflow steps. See Zapier's official webhook guide for the current setup procedure and plan availability.

Security: Treat the Zapier webhook URL as a secret. Anyone who obtains it may be able to submit data and trigger the Zap.

Integrating WAVER with Make

Make can receive WAVER data through a Custom webhook and use it as an instant trigger for a scenario. The event can then be filtered, transformed, routed, and sent to one or more application modules.

Make Configuration

1. In Make, create a new scenario.

2. Add Webhooks > Custom webhook as the first module.

3. Create and name the webhook.

4. Copy the webhook URL generated by Make.

5. Start listening for sample data in Make.

6. In WAVER, open Integrations > Webhooks.

7. Enable the webhook and select POST – JSON format.

8. Paste the Make webhook URL into Destination URL and click Save.

9. Click Test Webhook, or complete a test guest login.

10. Return to Make and confirm that the data structure has been detected.

11. Add filters, routers, and application modules as required.

12. Activate the scenario and configure it to run immediately when data arrives.

Make custom webhooks act as instant triggers and can pass the received data to other modules in the scenario. See Make's official webhook documentation for current behavior, queues, scheduling, and limits.

Security: Treat the Make webhook URL as a secret and provide access to the scenario only to authorized users.

What can be automated?

Once Zapier or Make receives a WAVER event, the data can be shared with the applications and actions available in the selected automation platform. A single guest login can trigger one or several actions.

Common examples include:

• CRM: Create or update a guest or lead in HubSpot, Salesforce, Zoho CRM, or another supported CRM.

• Email marketing: Add a consenting guest to Mailchimp, Brevo, ActiveCampaign, or another mailing platform.

• Spreadsheets and databases: Add login records to Google Sheets, Airtable, a database, or a reporting dataset.

• Notifications: Notify staff through Slack, Microsoft Teams, email, or another messaging service.

• Analytics: Send connection events to an analytics platform, data warehouse, or business-intelligence workflow.

• Loyalty and customer engagement: Update a customer profile, loyalty program, or post-visit communication flow.

• Custom systems: Forward the event to an internal API, property application, or custom reporting service.

The exact applications, actions, limits, and execution frequency depend on the Zapier or Make account and the third-party services being used.

Example: add consenting guests to an email platform

1. Receive the WAVER POST webhook in Zapier or Make.

2. Add a filter that continues only when marketing equals 1.

3. Confirm that the email field is not empty.

4. Create or update the contact in the selected email-marketing platform.

5. Optionally record the router identity and login time as custom fields.

Do not add a guest to a marketing list solely because they used the WiFi service. The marketing value should be checked before any marketing action is performed.

Example: send the event to several systems

One incoming WAVER webhook can be split into several routes. For example, the same event can:

• Update a CRM contact.

• Add a row to a reporting spreadsheet.

• Notify a staff channel.

• Add the guest to a mailing list only when marketing consent is present.

This allows WAVER to exchange data with hundreds of services through one automation workflow, even when those services do not have a direct WAVER integration.

OTP Webhook

Enable OTP Webhook only when the email or SMS verification code must be sent through a custom delivery provider. WAVER sends the OTP before the guest completes verification as a separate webhook event.

This can be used to connect a custom SMS gateway or transactional email service through an internal endpoint, Zapier, or Make.

Warning: OTP codes are authentication secrets. Do not send OTP events to general CRM, analytics, spreadsheet, or marketing workflows. Use a dedicated, trusted automation with restricted access and minimal logging. Disable OTP Webhook when custom OTP delivery is not required.

Testing and logs

• Test Webhook: Use this before deployment to send sample data and confirm that the destination can receive the request.

• Webhook Log: Displays recent webhook activity for troubleshooting.

• Export: Downloads the webhook log for further analysis.

• Clear: Permanently removes the locally displayed webhook log.

A successful webhook delivery confirms that the receiving endpoint accepted the request. It does not necessarily confirm that every later Zapier, Make, or third-party action completed successfully. Review the automation platform's execution history when troubleshooting downstream actions.

Important notes and best practices

• Always use an HTTPS destination URL.

• Prefer POST – JSON when sending personal or structured information.

• Send only the data required for the intended integration.

• Treat Zapier, Make, and custom webhook URLs as confidential credentials.

• Apply filters before forwarding data to additional services.

• Respect the guest's marketing-consent choice.

• Restrict access to webhook logs because they may contain personal information.

• Test with non-production guest data before enabling the workflow for all users.

• Review the receiving platform's privacy, retention, security, and data-processing settings.

• Fields vary by login method; design the workflow to handle missing values safely.