Webhook Verification Tester
Send your callback URL the same verification request Meta or Slack sends, and see exactly why it passes or fails: the token, the challenge, the status code, a redirect, the certificate or a timeout.
Test a callback URL
The request comes from Conferbot's server, so it reaches only public addresses, follows no redirects and stops after 5 seconds. The URL, token and reply are not logged or stored.
What Meta sends, and what it expects back
When you save a callback URL for the WhatsApp Cloud API, Messenger or Instagram, Meta calls it once with a GET request carrying three query parameters: hub.mode=subscribe, a numeric hub.challenge, and hub.verify_token, the string you typed in the App Dashboard. Your endpoint should compare the token with its own copy and, if they match, answer HTTP 200 with the challenge as the entire body. Anything else and the dashboard reports that the callback URL or verify token couldn't be validated.
Most failures are small. The handler exists only for POST, because that is where events arrive, so the GET falls through to a 404 or 405. The token is read from an environment variable that is not set in production. A framework serialises the challenge to JSON, which adds quotes. Or a trailing slash triggers a redirect. Meta also requires a valid certificate from a public authority; self-signed certificates are not supported, and a server that omits its intermediate certificate fails the same way. The step-by-step guide to fixing a failed Meta webhook verification walks through each, with working handlers.
Slack's url_verification, and why signing matters
Slack checks a Request URL with a POST instead. The JSON body has type: "url_verification" and a challenge, and your endpoint must return that challenge with HTTP 200, as plain text, as challenge=… form data, or as {"challenge": "…"}. Slack wants every event acknowledged within three seconds, so the handler should answer before doing any slow work.
Slack also signs its requests with your app's Signing Secret, using HMAC-SHA256 over v0:timestamp:body, and a well-built app rejects anything unsigned. That is why this tester asks for the secret and signs the request in your browser: the secret itself is never sent. If you leave it blank, a 401 or 403 is the right answer and the result says so. The common real failures are hashing a parsed body instead of the raw one, or using the bot token or the deprecated verification token in place of the Signing Secret. See Slack url_verification failures for the full list.
After the handshake
Verification proves only that the URL answers. Events still need a subscription to the right fields, and from then on every delivery is a POST that your webhook must acknowledge quickly, ideally after checking its signature. Meta signs deliveries with X-Hub-Signature-256 using your app secret, and Slack keeps signing with the Signing Secret.
If you would rather not run the endpoint at all, a WhatsApp chatbot or Slack chatbot built on Conferbot hosts it for you and handles the verification handshake and request signatures. When you do send messages yourself, the WhatsApp interactive message builder produces valid button and list payloads.
Webhook verification questions
Why does Meta say the callback URL or verify token couldn't be validated?
Meta sent a GET request to your URL with hub.mode, hub.challenge and hub.verify_token, and did not get the challenge back with HTTP 200. The usual causes are a token that differs from the one in your code, a handler that only accepts POST, a challenge returned as JSON instead of plain text, a redirect, or a certificate Meta does not trust. This tester shows which.
What does Slack's url_verification request expect?
When you save a Request URL, Slack POSTs a JSON body with type url_verification and a challenge string. Your endpoint must answer HTTP 200 with that challenge, as plain text, as challenge= form data, or as JSON with a challenge field. Slack signs the request, so a correct app checks X-Slack-Signature first and answers within three seconds.
Is it safe to paste my verify token or signing secret here?
Your Slack signing secret never leaves the browser: the page signs the test request locally and sends only the finished signature. For Meta, the verify token is sent once to your own URL, exactly as Meta would send it. Conferbot does not log or store the URL, the token or your endpoint's reply. Change the token afterwards if you prefer.
Can I test a localhost or ngrok URL?
Public tunnels such as ngrok or Cloudflare Tunnel work, because they give your machine a public HTTPS address, which is also what Meta and Slack need. Localhost, private network addresses and non-standard ports are refused on purpose: Meta and Slack could not reach them either, so a pass would be misleading.
My endpoint passes here but Meta still fails. Why?
Compare the exact URL and token you typed in the App Dashboard with what you tested, including the trailing slash and any query string. Then check the certificate chain, which this tester also validates, and whether a firewall or bot-protection service blocks Meta's servers but not ours. Some hosts challenge unknown traffic with a JavaScript page that Meta cannot pass.
Why does the tester send a second request with a wrong token?
To check that your endpoint really compares hub.verify_token. Meta only ever sends the right token, so an endpoint that echoes every challenge passes verification while letting anyone subscribe it to their own app. If your URL answers the wrong token with the challenge, the result shows a warning so you can add the comparison.
Related
Skip the webhook plumbing
Connect WhatsApp, Messenger or Slack to Conferbot and the endpoint, verification and signature checks are handled for you. Free plan, no card.