WhatsApp webhook tester

The webhook tester shows the JSON WhatsApp sends to your server when a message, status, or account event arrives.

A webhook is the address Meta calls on your server. During WhatsApp API setup you paste that address into the app settings and Meta sends a verification challenge. After that, every inbound message and delivery status is an HTTP request. If the server answers slowly, returns the wrong status, or expects a different JSON shape, the inbox looks empty even though the customer did send a message.

Use the tester before you point a production number at a new endpoint. Paste or inspect a sample payload, confirm the fields your code reads, and check that a test request reaches the URL you will register. This is the same check a developer does in a staging environment, without waiting for a live customer to send the first message.

The tester does not replace the WhatsApp Business API. It does not send messages to customers and it does not store your production token. It is a free debugging step for the integration. When the payload looks right, the next step is the Bulkwise inbox, where those events become conversations, chatbot replies, and agent assignments.

Teams usually open the tester while connecting a webhook for order alerts, a CRM, or a custom bot. Read the sample, match the phone number and message text fields, then register the live URL in the product. If Meta verification is still in progress, you can still learn the payload shape. Verification itself takes 3 to 5 business days on Bulkwise, including Meta’s review.

Start a free trial when you want those webhooks attached to a shared inbox, templates, and the channels you already pay for. Book a demo if you want the team to walk through the endpoint with you. Paid onboarding is ₹2,500, self-serve setup is free, and a 3-month plan includes paid onboarding.

Read the request headers as well as the body. Meta signs the call so you can confirm it came from WhatsApp rather than from someone replaying an old payload. Answer with a success status only after the server has accepted the event. An error status makes Meta retry, which helps when you were down and creates noise when your parser rejects a field you do not use. Log the event id, the phone number, and the timestamp, and skip the message body in long-term logs if support does not need it. When the same event arrives twice, update the existing conversation instead of opening a second one. That check is what stops a duplicate chatbot reply, which is the failure a customer notices first.