How to Test Webhooks Online Without Installing Anything

Testing a webhook usually starts with one problem: the provider needs a public HTTPS URL, but your application is running on localhost. A tunnel can expose your machine, but it adds installation, authentication, and another process to manage.

When you only need to inspect what a provider sends, an online webhook inspector is faster. It gives you a temporary public endpoint and shows each request in your browser.

Test a webhook in three steps

1. Create an endpoint

Open OpenWebhook. A unique URL is generated immediately in this format:

https://openwebhook.co/0198f4c2-...-6abc-.../

There is no signup, package, CLI, configuration, or credit card form. Keep the page open because requests are relayed live and are not stored on the server.

You can append a meaningful path without creating another endpoint:

https://openwebhook.co/YOUR_UUID/github
https://openwebhook.co/YOUR_UUID/stripe
https://openwebhook.co/YOUR_UUID/staging/orders

All of these paths appear in the same session.

2. Configure or send the webhook

Paste the URL into the provider's webhook destination field. If you are testing your own code, send an HTTP request with cURL:

curl -X POST \
  'https://openwebhook.co/YOUR_UUID/orders?environment=test' \
  -H 'content-type: application/json' \
  -H 'x-event-type: order.created' \
  --data '{
    "id": "order_42",
    "total": 12900,
    "currency": "EUR"
  }'

The endpoint accepts common methods including GET, POST, PUT, PATCH, and DELETE. JSON, text, form data, and binary bodies are captured up to the configured size limit.

3. Inspect and reproduce

Select the request in the left panel. Check:

• the exact method and path;
• all request headers;
• repeated and encoded query parameters;
• the parsed JSON body and raw body;
• source IP, payload size, and receive time.

Use Copy cURL to create a command that reproduces the selected request. This is useful when moving from observation to debugging your actual endpoint.

Verify more than the JSON body

Webhook bugs frequently live outside the body. Check the following before changing application code.

Content type

A provider may send application/json, application/x-www-form-urlencoded, or a vendor-specific media type. Make sure your framework activates the correct body parser.

Signature headers

Providers typically sign either the raw body or a timestamp plus the raw body. Record the exact signature and timestamp headers. Parsing and re-serializing JSON before verification changes bytes and can invalidate a correct signature.

Query strings

Some systems put environment, tenant, or challenge values in the query string. Repeated keys such as tag=a&tag=b should not silently collapse to one value.

Redirects

Avoid redirecting webhook requests. Some HTTP clients change a POST to a GET after a redirect, and providers may refuse redirects entirely. Configure the final HTTPS URL from the start.

Test failure behavior deliberately

An inspector confirms what is being sent, but your production handler must also respond correctly. Test these cases against your own endpoint:

# Wrong content type
curl -X POST https://api.example.com/webhooks \
  -H 'content-type: text/plain' \
  --data '{"event":"test"}'

# Duplicate delivery
for i in 1 2; do
  curl -X POST https://api.example.com/webhooks \
    -H 'content-type: application/json' \
    --data '{"id":"evt_same","type":"test"}'
done

Confirm that invalid signatures return an appropriate 4xx, duplicate event IDs do not repeat side effects, and valid events receive a quick 2xx.

When to use a tunnel instead

Use an online inspector when you need to learn the payload, compare providers, capture headers, or share a reproducible request. Use a local tunnel when the provider must exercise your application code directly, including signature verification and database writes.

A productive workflow often uses both: inspect the real request first, then replay it against the tunneled local handler.