Webhook Endpoint Checker

Server assisted New Web Utilities

Enter the URL that should receive webhooks and the Mutqan server sends it one POST with a fixed JSON test body (type "mutqan.webhook_check", a random id and the time of the check) and one OPTIONS request, then reports what a webhook sender would run into: the status code, the time to answer, plain HTTP, a redirect (reported, not followed), missing headers and the first 2,048 characters of the reply. Nothing you type except the URL is sent, so the check cannot replay a real event or carry a signature.

Privacy: The Mutqan server sends the small, fixed test requests described on this page to the host you name, and nothing is stored. Use it only against systems you are authorised to test.

What must a webhook endpoint do to receive deliveries reliably?

Answer the POST over HTTPS with a 2xx quickly — providers such as GitHub expect one within 10 seconds — at the exact registered URL, because many senders do not follow redirects and treat anything but a 2xx as a failure to retry. It should verify the sender's signature over the raw body before acting, refuse unsigned requests, and do the real work after acknowledging, so that slow processing does not cause duplicate deliveries.

Security note: A webhook URL is public: anyone who learns it can post to it. Verify the signature with a constant-time comparison, reject old timestamps, and never treat the payload as trusted input.

How to use Webhook Endpoint Checker

  1. Enter the URL you registered (or will register) with the webhook provider, for example https://api.example.com/webhooks/incoming.
  2. Press Check the endpoint. The Mutqan server sends the test POST and the OPTIONS request once each.
  3. Read What a webhook sender would see from the top: the first row says whether the delivery would count.
  4. If the endpoint refused the unsigned test with 400, 401 or 403, that is expected for a signed endpoint; send a signed test event from the provider to check the accepted path.

Webhook Endpoint Checker features

  • Sends one test delivery the way a webhook provider would — a JSON POST — plus one OPTIONS request, and shows how the endpoint answered
  • Explains the status as a sender would treat it: delivered (2xx), redirected and lost, refused because it is signed (400, 401, 403), not found, not allowed, failing (5xx)
  • Times the answer and flags anything slower than 3 seconds, the point where senders start to give up and retry
  • Reports plain HTTP, a redirect (with where it points, not followed), a missing Content-Type and a Retry-After header
  • Shows the response headers that matter for webhooks and the first 2,048 characters of the reply, as text
  • Shows exactly what was sent: a fixed body with a random id and the time, never your data and never a real event

Inputs and outputs

Inputs

  • Webhook URL — the http:// or https:// address the provider delivers to; "example.com/hook" gets https://. User names and passwords in the URL are refused.
  • Nothing else: the method, headers and body are fixed and cannot be changed.

Outputs

  • Summary — the HTTP status of the POST, the time it took, whether the URL is HTTPS, and the status of the OPTIONS request.
  • What a webhook sender would see — each check with its result: the delivery, HTTPS, the response time, the Content-Type, the OPTIONS answer and Retry-After.
  • Response headers and Response body — the headers that matter for webhooks (Content-Type, Server, Allow, Retry-After, X-Request-Id, CORS) and the first 2,048 characters of the reply, shown as text.
  • What was sent and About this check — the two requests exactly as the server sends them, and what the check cannot tell.

Webhook Endpoint Checker example

A signed webhook receiver refusing the unsigned test, as it should

Input:

https://hooks.example.com/payments/events

Output:

Summary: HTTP status 401 · Response time 184 ms · Encrypted (HTTPS) Yes · OPTIONS answer 204
What a webhook sender would see: Accepts the test POST — Info (refused, which is right for an endpoint that verifies a signature or a token) · HTTPS — Passed · Response time — Passed (within 3 seconds) · Content-Type of the answer — Info · OPTIONS request — Info
Response headers: content-type application/json · x-request-id 7f3c9a
Response body: {"error":"invalid signature"}

How to read the Webhook Endpoint Checker results

Passed on the first row (2xx) means a real delivery would very likely be accepted too, unless the endpoint checks something this test cannot send, such as a signature.

Info with 400, 401 or 403 is the expected answer from an endpoint that verifies signatures or tokens: the route exists and protects itself. It is not proof that real events will pass.

Failed with a redirect means deliveries go nowhere; register the URL the redirect points to. Failed with 404 or 405 usually means a wrong path or a route that only accepts GET.

A response time above 3 seconds is a warning, not a failure: senders differ, but most give up after 5 to 10 seconds and retry, which can deliver the same event twice.

When to use Webhook Endpoint Checker

  • Before registering a webhook URL with a payment, Git or messaging provider: is it reachable, HTTPS, fast and not redirecting?
  • After a deployment or a DNS change, when deliveries suddenly fail with timeouts or 404s.
  • Confirming that a signed endpoint refuses unsigned requests instead of processing them.
  • Checking a receiver behind a proxy or API gateway that may add a redirect or slow it down.

Troubleshooting

  • "The endpoint did not answer in time": nothing answered within 10 seconds. Check that the service is running and reachable from the internet, not only from your network.
  • "Webhook checks are limited to 20 per 10 minutes for each address": wait for the time shown; the limit protects the endpoints being tested.
  • The answer is an HTML page with 403: a firewall or bot protection is answering, not your application. Allow the provider's addresses, as its documentation lists them.
  • The test triggered your handler: the endpoint accepts unsigned JSON. Ignore the type mutqan.webhook_check or the X-Mutqan-Webhook-Check header, and consider requiring a signature.

Frequently asked questions about Webhook Endpoint Checker

What exactly does the check send?

One POST with the body {"type":"mutqan.webhook_check","id":…,"sentAt":…} (a random UUID and the time of the check), Content-Type: application/json, User-Agent: MutqanTools-WebhookCheck/1.0 and X-Mutqan-Webhook-Check: 1, then one OPTIONS request with the same two identifying headers. The Mutqan relay adds X-Mutqan-Relay: 1 to both. There is no signature, no cookie and nothing you typed except the URL; the What was sent block shows both requests.

My endpoint answered 401, 403 or 400. Is it broken?

Probably not. An endpoint that verifies the sender's signature or a shared token must refuse an unsigned test like this one, and that refusal shows the route exists and is protected. To test the accepted path, send a signed test event from the provider's dashboard, or point the provider at the Webhook Tester to see what it really sends.

Why is a redirect reported as a problem?

Many webhook senders do not follow redirects, and those that do often turn a POST into a GET after a 301 or 302, so the delivery is lost or arrives without its body. Register the final URL with the provider instead.

How fast does the endpoint need to answer?

Senders wait only a few seconds — GitHub, for example, expects a 2xx within 10 seconds — and then retry or mark the delivery as failed. Acknowledge at once and do the work in the background; this check flags any answer slower than 3 seconds and gives up after 10.

Will the test trigger my business logic?

It can, if the endpoint accepts unsigned JSON. The body's type, mutqan.webhook_check, is sent by no real provider, and every request carries X-Mutqan-Webhook-Check: 1, so you can recognise and ignore it.

How many checks can I run?

Twenty per 10 minutes from one address, on top of the per-minute allowance shared with the other tools that contact sites for you. When the limit is reached the page says how long to wait.

Technical notes

A webhook is an HTTP POST from a provider to a URL you register. Senders treat any 2xx answer as a delivery and anything else — a 3xx, 4xx, 5xx or a timeout — as a failure to retry later (RFC 9110 defines the status classes). Many do not follow redirects, and a client that does may change POST into GET after a 301 or 302 (RFC 9110 §15.4), so the body is lost.

The check makes exactly two requests from the Mutqan server: a POST with Content-Type: application/json, the User-Agent MutqanTools-WebhookCheck/1.0, X-Mutqan-Webhook-Check: 1 and the body {"type":"mutqan.webhook_check","id":…,"sentAt":…}, then an OPTIONS with the same two identifying headers; the relay adds its own X-Mutqan-Relay: 1 header to both. The host must resolve only to public addresses, each request waits up to 10 seconds, and redirects are not followed.

Signed webhooks put an HMAC or a signature over the raw body in a header (HTTP Message Signatures, RFC 9421, standardise one form). Because this test is unsigned, a correctly built receiver rejects it; the Webhook Signature Analyzer helps verify a signature you captured.

Limitations and methodology

It is not a request proxy and cannot replay a real event: the body, the headers and the method are fixed, and no signature is sent, so an endpoint that verifies signatures can only show its refusal.

One delivery is a snapshot from the Mutqan server's network; providers send from their own addresses, which a firewall may treat differently, and they retry on their own schedule.

Only the first 2,048 characters of the reply and a subset of its headers are shown; the endpoint's processing after it answered cannot be seen.

Security and privacy

Only the URL leaves your browser. The Mutqan server sends the endpoint a fixed test body with a random id and the time, never your data, and stores nothing; use it only on endpoints you are allowed to test.

References

  • Best practices for using webhooksGitHub DocsA provider's own rules for receivers: use HTTPS, verify the webhook secret, answer with a 2xx within 10 seconds and process asynchronously, and handle redeliveries.
  • RFC 9110: HTTP SemanticsIETF · 2022The meaning of HTTP methods, header fields, status codes and content negotiation, independent of the wire version.
  • RFC 9421: HTTP Message SignaturesIETF · 2024A standard way to sign HTTP messages so a receiver can verify their origin and integrity — the basis of modern webhook signatures.