Does this give me a unique inbox URL like other webhook testers?

No. This site has no backend to receive traffic on your behalf, so instead of an inbox URL, this tool is the other half: it sends a real test request to a URL you already have, such as your own webhook receiver or a request-inspection service, and shows you exactly what came back.

Why did my request fail with no useful error?

The most common cause is CORS: browsers block cross-origin responses from being read by page JavaScript unless the target server explicitly allows it, so many real APIs and webhook endpoints will fail here even though the request itself reached the server. Check your browser's network tab to see if the request actually completed.

Is my request sent to this site's servers first?

No. The request is made directly from your browser to the URL you entered using the standard fetch API. This site never sees the URL, headers, or body you're testing with.

Webhook Tester - Send a Test Webhook Request Online

Overview

Introduction

Testing a webhook receiver usually means triggering the real event that fires it, which is slow when you just want to check that your endpoint parses a payload correctly.

This tool skips that by sending a request you fully control, method, headers, and body, directly to your endpoint from your browser, so you can see exactly what it receives and sends back.

What Is Webhook Tester?

A manual HTTP request sender built for webhook-shaped traffic: pick a method, add headers, write a body, and fire it at any URL.

It's part of this site's API Tools collection and runs entirely client-side; the request itself, of course, does leave your browser, since that's the point.

How Webhook Tester Works

Your inputs are assembled into a standard fetch() call made directly from the browser to the URL you provide, with no intermediary server.

The response status, headers, and body are read back and displayed as soon as they arrive, or an error is shown if the browser couldn't complete the request at all.

When To Use Webhook Tester

Use it to check that a webhook receiver you're building parses a specific payload shape correctly, without waiting for the real event to occur.

It's also useful for confirming a receiver's response (status code, headers) matches what a webhook provider expects for a successful delivery.

Often used alongside GraphQL Query Tester.

Features

Advantages

Full control over method, headers, and body, not tied to any one provider's payload format.
Shows the exact response status, headers, and body your endpoint returned.

Limitations

No inbox/receiving URL is provided; you need an endpoint of your own (or a third-party request bin) to send to.
Requests to endpoints without permissive CORS headers will fail to return a readable response, even though the request may have succeeded server-side.

Examples

Testing a JSON payload against a local endpoint

Input

POST https://example.com/webhook with header Content-Type: application/json and body {"event":"order.created"}

Output

HTTP 200 OK — 142ms
content-type: application/json

{"received":true}

The request is sent exactly as configured, and the endpoint's real response is shown back verbatim.

Hitting an endpoint that blocks cross-origin requests

Input

POST https://an-api-without-cors.example.com/hook

Output

Request failed before a response came back...

The browser blocks the response from being read because the server didn't send permissive CORS headers, even if the request itself was received.

Best Practices & Notes

Best Practices

Point this at a local tunnel (like ngrok) or a request-inspection service while developing a webhook receiver, not directly at production.
Set the same Content-Type header your real webhook provider sends, since many receivers branch on it.
Read the response body carefully; a 200 with an unexpected body often means your endpoint accepted the request but rejected the payload logically.

Developer Notes

Requests are made with the browser's native fetch() and no custom headers are added beyond what you specify, aside from whatever the browser itself always sends (like Origin and User-Agent), so the request your endpoint sees matches what you configured as closely as a browser environment allows.

Webhook Tester Use Cases

Verifying a webhook receiver parses a specific event payload correctly before wiring it to a real provider
Reproducing a failed webhook delivery by resending the same method, headers, and body
Checking what headers and body an endpoint sends back for a given request

Common Mistakes

Assuming a failed request here means the endpoint is down, when it's often just a CORS policy blocking the browser from reading the response.
Forgetting to set Content-Type, which causes some receivers to skip parsing the body entirely.

Tips

Open your browser's network tab alongside this tool to see the exact request that went out, in addition to the parsed response shown here.

Webhook Tester