Use a lightweight gateway for Meta verification, then forward approved WhatsApp events into Zapier for downstream automation.

Prerequisites

An active Dualhook connection
A lightweight HTTPS gateway endpoint that you control
Your Meta webhook verify token (for the GET handshake — set during connection setup in Dualhook)
Your WABA_ID and PHONE_NUMBER_ID for payload-side validation in the gateway
A Zapier account with either:
- Webhooks by Zapier for receiving forwarded events, or
- API by Zapier / Webhooks by Zapier for outbound Graph API requests

If you need a starting point for the gateway itself, use one of the direct receiver guides:

Why Zapier Is Not the Direct Meta Webhook Receiver

Dualhook's direct-routing model expects your Meta callback URL to complete Meta's verification handshake:

Meta sends GET with hub.mode, hub.verify_token, and hub.challenge
your endpoint must return the raw hub.challenge body with 200

Zapier's Catch Hook and Catch Raw Hook triggers can receive webhook traffic, but they do not provide the response control needed to reliably act as the Meta verification endpoint. That makes Zapier a poor fit for the first hop in a Dualhook webhook flow.

Zapier is still useful after the first hop. The safe pattern is:

a small gateway endpoint receives Meta webhooks
the gateway validates the payload and responds to Meta
the gateway forwards approved events into Zapier

No META_APP_SECRET? In the Embedded Signup flow X-Hub-Signature-256 is signed by Dualhook's Meta app and isn't customer-verifiable — the gateway validates inbound webhook payload shape instead. See Messaging Webhook → Inbound Webhook POST Validation.

Architecture Overview

Meta (messages, statuses, errors)
  -> Your gateway endpoint
     -> GET verification (verify_token)
     -> inbound payload validation (envelope, WABA ID, phone_number_id)
     -> fast 200 to Meta
     -> forward normalized event to Zapier

Zapier
  -> downstream automation
  -> optional Graph API sends

Dualhook
  -> setup, monitoring, template operations, management events

This keeps Dualhook out of message storage while still acknowledging that your gateway and Zapier can both become storage layers if they keep request bodies, task history, or logs.

Build the Gateway Endpoint

The gateway can be a small Node.js service, Laravel controller, edge function, or similar HTTPS endpoint. It must do four things reliably.

1. Handle GET verification

For GET verification requests:

verify that hub.mode is subscribe
compare hub.verify_token to your expected token
return the raw hub.challenge value with 200
return 403 on mismatch

2. Validate inbound POST payloads

For POST webhook requests:

confirm object === "whatsapp_business_account"
confirm entry[].id equals your stored WABA_ID
confirm entry[].changes[].field is messages
confirm value.metadata.phone_number_id is present and equals your stored PHONE_NUMBER_ID
return 401 and stop if any check fails

3. Respond quickly

Return 200 to Meta immediately after inbound payload validation passes. Do heavy work asynchronously.

4. Forward a normalized event into Zapier

Forward only what Zapier needs. A practical forwarded shape includes:

{
  "trace_id": "internal_trace_id",
  "received_at": "2026-04-08T12:00:00Z",
  "event_type": "messages",
  "phone_number_id": "123456789012345",
  "payload": {
    "object": "whatsapp_business_account",
    "entry": []
  }
}

If you want the gateway reference implementation, adapt the verification and payload-validation logic from Node.js Webhook Receiver or Laravel Webhook Integration.

Trigger Zapier from the Gateway

If the gateway is forwarding normalized JSON, Catch Hook is usually the simplest Zap trigger. Use Catch Raw Hook only when you deliberately want the forwarded body unparsed and are sure it stays within Zapier's size limits.

Recommended pattern:

Build a Zap with Webhooks by Zapier as the trigger.
Copy the Zapier hook URL.
Have the gateway POST the normalized event to that URL after Meta has already received 200.
Continue the rest of your automation in Zapier.

This split keeps the Meta-facing contract under your control and keeps Zapier focused on downstream automation, notifications, enrichment, or app-to-app steps.

Send Template Messages via Graph API

For outbound sends from Zapier, prefer API by Zapier when you want credentials stored in an app connection rather than inside a Zap step. Use Webhooks by Zapier only when simple auth or no auth is enough and you accept step-level credential visibility.

Preferred: API by Zapier

Use API by Zapier -> API Request with:

Method: POST
URL: https://graph.facebook.com/v25.0/<PHONE_NUMBER_ID>/messages
Authentication: static headers or OAuth if your setup requires it
Domain filter: restrict to graph.facebook.com

Simpler fallback: Webhooks by Zapier

If you are comfortable with step-level auth handling, Webhooks by Zapier can also send the request:

Method: POST
Headers:
- Authorization: Bearer <WHATSAPP_ACCESS_TOKEN>
- Content-Type: application/json

Example template send:

{
  "messaging_product": "whatsapp",
  "to": "12015550123",
  "type": "template",
  "template": {
    "name": "order_update_v1",
    "language": { "code": "en_US" }
  }
}

See Sending Template Messages for richer payload patterns.

Test with Dualhook

Put the gateway URL, not the Zapier URL, into Dualhook as the webhook URL.
Use the same verify token in Dualhook and in the gateway.
Confirm the gateway completes Meta verification successfully.
Run Dualhook Test Ping to confirm the endpoint is reachable.
Send a real WhatsApp message to your number.
Confirm that:
- the gateway accepts real Meta payloads and rejects unrelated test pings
- Meta receives a fast 200
- the gateway forwards the event to Zapier
- the Zap runs on the forwarded event

Production Caveats

Do not use Zapier as the primary durability layer for Meta webhooks. The gateway should own retries, idempotency, and backoff when Zapier is slow or rate-limited.
Zapier can delay processing under high load, and webhook/task histories can retain payload data. Treat that as part of your compliance boundary.
Catch Raw Hook payloads are capped at 2 MB. Keep forwarded events small and predictable.
Use idempotency in the gateway before forwarding and in Zapier before acting on repeated events.
Treat message payloads as evolving. The BSUID rollout makes some identifiers conditional, so your gateway normalization should not assume phone-number-based fields are always present. See BSUID Transition Guide.

Zapier Webhook Integration