Skip to main content
When a user sends a message to your WhatsApp number, or when the delivery status of an outbound message changes, the Connexease Gateway forwards that event to your server as an HTTP POST request. This page explains how to register your endpoint, what each event payload looks like, and how to handle retries and failure scenarios correctly.

How It Works

  1. Meta sends a webhook to the Connexease Gateway.
  2. The Gateway verifies the signature and forwards the event to your registered webhook URL.
  3. Your server must return HTTP 200. Heavy processing must be done asynchronously.

Setup

Step 1 — Register Your Webhook URL

DashboardSettings → Webhooks → enter your URL and set a webhook secret.

Step 2 — Choose Your Events

Select the events your application should receive:

Step 3 — Prepare Your Endpoint

Your webhook endpoint must:
  • Be accessible over HTTPS with a valid SSL certificate
  • Return HTTP 200 within 5 seconds
  • Handle heavy operations asynchronously (background job, queue)

Retry Policy

If your server returns a connection error or HTTP 5xx, the Dispatcher retries: After 3 failed attempts, the event is dropped and logged to ClickHouse with ProcessingStatus: ERROR.
HTTP 4xx responses are treated as permanent failures and are not retried. If you return 401 Unauthorized (e.g. wrong secret), the event is lost.

Incoming Message Payloads

Text Message

Field Reference:

Image Message


Audio Message


Document Message


Interactive — Button Reply

Received when a user taps one of the buttons you sent:

Interactive — List Reply

Received when a user selects an item from a list you sent:

Location Message


Status Update Payloads

Sent

Delivered

The Gateway automatically deducts the Meta fee when status: "delivered" and pricing.billable: true.
Status Update Field Reference:

Read

Failed


System Event Payloads

Template Status Update

Account Update


Key Notes

No delivery order guarantee. sent and delivered events may not arrive in order. Sort by statuses[0].timestamp.
Idempotency: Network issues or the retry mechanism may deliver the same wamid more than once. Make your processing logic idempotent (safe to run multiple times for the same ID).
Quick test: Messages sent with is_fake=true do not generate delivered webhooks. Use a real number or Meta’s test phone numbers to test the full webhook flow.

Checklist

1

Is your HTTPS endpoint publicly accessible?

Must have a valid SSL certificate and be reachable from the internet.
2

Are you returning HTTP 200 within 5 seconds?

Move DB writes, API calls, and emails to a background job.
3

Are you validating the Authorization header?

Without the Bearer WEBHOOK_SECRET check, you’re open to forged events.
4

Is your processing idempotent?

Ensure the same wamid cannot trigger duplicate side effects.
5

Have you subscribed to the right events?

At minimum, messages and message_status should be active in the Dashboard.