What Is Hookdeck Inspect? The Beginner's Guide to Testing Webhooks Without Any Setup
CodexFuse Team · 2026-11-05T08:17:14.797Z · 21 min read min read
What Is Hookdeck Inspect? The Beginner's Guide to Testing Webhooks Without Any Setup
What Is Hookdeck Inspect?
If you have asked what is hookdeck inspect, the short answer is that it is a free webhook tester that gives you an instant, public URL for receiving and inspecting webhooks, with no account and no setup. Open inspect.hookdeck.com, copy the URL it hands you, and paste it wherever a provider expects a webhook endpoint. Every request that arrives is displayed in real time with its method, headers, body, and query parameters, so you can see exactly what a provider sends before you write a single line of handler code.
Hookdeck Inspect is a web-based webhook payload inspector from Hookdeck, the company behind managed webhook infrastructure. It was formerly called Hookdeck Console, and it was relaunched under the Inspect name in early November 2026. The rename is more than cosmetic, because the new version is built around three ideas: inspect anything in seconds, test with realistic provider payloads, and hand the same workflow to an AI agent or a local server when you are ready.
Inspecting a payload matters because providers rarely send exactly what their documentation promises. A Stripe event can carry nested objects you did not expect, a Shopify webhook can include fields your parser ignores, and a GitHub push event can arrive with a signature header your code never checks. Seeing the real request once saves hours of guessing, and a free webhook tester is the fastest way to see it.
If you want to sanity-check a signature or a hash before you trust a payload, the same instinct applies to a SHA-256 hash generator, which verifies a file or string in seconds. If your handler will eventually run on a server, the same isolation instinct applies to VPS hosting, where your webhook endpoint lives on infrastructure you control.
How Does Hookdeck Inspect Work?
Hookdeck Inspect works by giving you a unique source URL and showing you everything that hits it. The full loop takes about a minute, and it needs no account, no installation, and no tunnel. Here is the arc from zero to your first inspected payload.
- Open inspect.hookdeck.com in your browser and copy the unique URL it generates for you, which looks like https://inspect.hookdeck.com/e/ followed by a random string.
- Paste that URL into the webhook settings of the provider you want to test, such as Stripe, Shopify, GitHub, or Twilio.
- Trigger a test event from the provider, or fire a mock payload from the built-in Webhook Library.
- Watch the request appear in Inspect in real time, with its method, headers, body, query parameters, and path.
- Copy the request as cURL, save it for later, or forward it to your local server with the Hookdeck CLI.
Behind the scenes, Inspect is built on the same source and destination concepts as the rest of the Hookdeck platform. A source is the URL that receives requests, and a destination is where those requests go next, either an HTTP endpoint or your local machine through the CLI. You can create multiple sources, so one URL can collect Stripe events while another collects GitHub events, and each stream stays separate.
That separation matters when you are debugging two providers at once, because mixed traffic in a single bin is how payloads get misread.
A webhook is simply an HTTP request a provider sends your server when something happens, and if the term is new to you, start with what a webhook is before you dig into the inspection details. Inspect exists because that request is invisible by default: your server logs it only if you wrote logging code, and a provider dashboard shows you only what the provider chose to record. Inspect puts the raw request in front of you, exactly as it arrived.
How Do You Test Webhooks Without an Account?
You test webhooks without an account by opening Inspect and using the URL it gives you immediately, with nothing to sign up for and no credit card to enter. The URL works the moment it appears, and requests sent to it show up in your browser in real time. That is the whole point of a free webhook tester: the time between deciding to inspect a payload and seeing it should be measured in seconds, not in signup forms.
Developers searching for a way to test webhooks without account friction land here for exactly that reason.
The no-account mode is genuinely usable, not a demo. You can inspect payloads, search inside them, copy them as cURL, and fire mock webhooks from the provider library without ever creating a Hookdeck account. The tradeoff is persistence: without an account, your history is tied to the browser session, and there is no workspace to share with teammates.
Creating a free Hookdeck account unlocks the Developer plan, which keeps 3 days of event history and up to 10,000 events per month, and lets you organize inspection sessions into a shared workspace.
Do the arithmetic on that free allowance before you assume it is small. Ten thousand events a month works out to about 333 events a day, and with 3-day retention you can look back at roughly 1,000 recent events at any moment. A developer testing a new Stripe integration might fire 50 to 100 events in a busy debugging session, which means the free tier covers roughly 100 to 200 such sessions a month.
You will hit the limit only if you point production traffic at Inspect, which is not what it is for.
What Do You See When You Inspect Webhook Payloads?
When you inspect webhook payloads in Hookdeck Inspect, you see the complete HTTP request, not a summary of it. The inspection view breaks the request into its parts so you can check each one against what your handler expects. That completeness is what separates a real inspector from a log line.
| Part of the request | What Inspect shows you | Why it matters when debugging |
|---|---|---|
| Method and path | POST, GET, or another verb, plus the exact path the provider called | Confirms the provider is hitting the endpoint you configured |
| Headers | Every header, including signature headers such as Stripe-Signature | Lets you verify authentication before you trust the body |
| Body | The full JSON or form payload, formatted and searchable | Shows the real field names and nesting your code must parse |
| Query parameters | Each key and value from the URL query string | Catches parameters your handler silently ignores |
| Timing | When the request arrived, down to the second | Helps you match a payload to a provider-side event or retry |
Two features in that view do more work than they first appear to. In-payload search lets you find a single field inside a large nested JSON body, which matters when a provider sends a payload several hundred lines long and the one value you need is buried five levels deep. Copy as cURL turns any captured request into a terminal command, so you can replay the exact same request against your local handler without re-triggering it from the provider.
That pair, search plus reproduce, is what turns inspection into debugging.
You can also save a captured payload for later use. Saved payloads carry over into the Hookdeck Event Gateway, which means a Stripe event you inspected on Monday can become the test fixture for a production connection on Friday. That continuity is unusual: most request catchers treat each capture as disposable, and the fixture you needed yesterday is gone.
What Is the Hookdeck Webhook Library?
The Hookdeck Webhook Library is an open-source collection of vendor-specific webhook payloads from more than 500 providers, built into Inspect so you can send realistic mock webhooks without configuring a single provider integration. Pick a provider and an event type, and Inspect fires a real-world payload at your source URL or directly at your local server. The samples are shaped like the events those providers actually send, not generic placeholders.
The library solves the cold-start problem of webhook development. Normally, testing a Stripe handler means creating a Stripe account, configuring a webhook endpoint, and triggering a test event from the Stripe dashboard, and you repeat that setup for every provider. With the library, you can send a mock webhook payload for Stripe checkout.session.completed, a Shopify orders/create event, a GitHub push event, or a Twilio inbound SMS in a few clicks, before any of those providers knows your endpoint exists.
That is why the mock webhook payloads stripe developers search for are a real use case, not a shortcut: the mock is the first test, and the live provider event is the confirmation.
Mock payloads have one honest limit worth stating once. A mock proves your handler parses the shape correctly, but it does not prove the provider will send that exact shape tomorrow, and it does not carry a valid signature header. Always confirm with at least one real event from the provider before you ship, and verify the signature header on that real event.
The library gets you to a working handler fast, and the live event is what certifies it.
How Do You Forward Webhooks to Localhost with the Hookdeck CLI?
Forwarding webhooks to localhost is the step that turns Inspect from a viewer into a development workflow, and the Hookdeck CLI is how you do it. Run one command in your terminal, and the same events you inspected in the browser arrive at your local server, where your handler code can process them. You debug with your IDE, your breakpoints, and your real code, instead of copying JSON into curl by hand.
hookdeck listen 3000
That single command opens a webhook-aware connection between your Inspect source and the server running on port 3000 of your machine. The CLI shows a terminal UI with the same inspection view you saw in the browser, including headers, body, and response, and every event can be replayed after you fix a bug. There is no separate tunneling tool to install, and the CLI needs no account to start.
Filtering flags narrow the stream when you only care about certain events, for example by header values, body content, path, or query parameters.
Replay is the feature that pays for the setup. When your handler has a bug, you fix the code and replay the original event instantly, with the original headers intact. Without replay, you re-trigger the event from the provider, wait for it to arrive, and hope the provider sends the same payload twice, which it often does not.
A realistic loop looks like this: inspect the payload, forward it to localhost, watch your handler fail, fix one line, replay the same event, and watch it pass. That loop is the reason Inspect pairs with the CLI instead of standing alone.
If you want to reproduce a single captured request outside the CLI, copy it as cURL from Inspect and run it against your local server. The command below posts a minimal JSON body to an Inspect URL, and the request appears in the dashboard the same way a provider event would.
curl -X POST https://inspect.hookdeck.com/e/your-source-id \
-H "Content-Type: application/json" \
-d '{"type": "checkout.session.completed", "test": true}'
How Does Hookdeck Inspect Work with AI Agents?
Hookdeck Inspect works with AI agents through the simplest possible interface: a URL. Share your Inspect URL with Claude Code, Codex, or another coding agent, and the agent can read requests as they arrive, tell you when one lands, and use the payload to build your handler. No MCP server, no skills file, and no other setup is required for that basic loop, because the agent reads the same web view you do.
The agent angle goes deeper than screen-sharing a URL. Hookdeck's own documentation describes delivery timeouts of up to 15 minutes for long-running agent runs, so an agent that needs several minutes to finish its work inside a request does not get cut off mid-task. That timeout is 900 seconds, which is 90 times longer than a typical 10-second provider timeout, and it exists precisely because agent workflows do not finish in the few seconds a normal API call allows.
Concurrency limits cap how many deliveries run at once, which keeps an agent workflow inside a model provider's rate limits instead of tripping them.
The CLI also ships an MCP server, agent skills, and AI documentation resources, so agents that do connect through the CLI get structured access to the same inspection data. If you build with agents regularly, the workflow in how to use Claude Code shows the setup habits that make an agent productive, and Inspect fits the same pattern: give the agent a real artifact to read, in this case a live payload, and let it work from evidence instead of guesses. The practical result is that an agent can watch a Stripe event arrive, read the exact field names, and write a handler that parses them, all without you pasting JSON into a chat window.
What Does Hookdeck Inspect Cost?
Hookdeck Inspect itself is free to use with no account required, and the paid plans belong to the wider Hookdeck Event Gateway platform. The free Developer plan costs 0 dollars a month and includes 10,000 events, 3-day retention, and one user. Paid plans start at 39 dollars a month for the Team plan, which keeps the same 10,000 included events but extends retention to 7 days and allows unlimited users.
The Growth plan starts at 499 dollars a month with 30-day retention, uptime and latency SLAs, and compliance features. Enterprise pricing is custom.
| Plan | Price | Included events per month | Retention | Users |
|---|---|---|---|---|
| Developer | 0 dollars per month | 10,000 | 3 days | 1 |
| Team | Starts at 39 dollars per month | 10,000 | 7 days | Unlimited |
| Growth | Starts at 499 dollars per month | 10,000 | 30 days | Unlimited |
| Enterprise | Custom | Custom | Custom | Unlimited |
The numbers tell a clear story about what you are paying for. Going from the Team plan at 39 dollars to Growth at 499 dollars is roughly a 12.8 times price increase, while retention grows from 7 days to 30 days, about 4.3 times, and the included event count does not change at all. The extra money buys SLAs, compliance, metrics export, and support, not more events.
Additional events beyond the included 10,000 are metered, with pricing as low as 0.33 dollars per 100,000 events on the pay-as-you-go scale. If you exceed 10,000 events on the free Developer plan, Hookdeck keeps receiving your events, but the dashboard locks until you upgrade or a new billing period begins, so treat the limit as a ceiling on visibility, not on ingestion.
One more arithmetic check puts the free tier in context. The included throughput is 5 events per second per destination, which works out to 300 events a minute, or 18,000 an hour, far above what a debugging session generates. The binding constraint for a free user is retention, not speed: 3 days means a payload you inspected on Monday is gone by Friday.
If your debugging sessions span a working week, the Team plan's 7-day retention is the first upgrade worth paying for.
Hookdeck Inspect vs Webhook.site vs RequestBin vs Beeceptor
Choosing a webhook inspector is a tradeoff between speed, depth, and where the workflow leads. Hookdeck Inspect is the strongest choice when you need more than a request catcher, because the sample library, the CLI, and the path to production are all part of the same product. The alternatives each win on a narrower job, and the table below shows where each one stands on the capabilities that matter.
| Capability | Hookdeck Inspect | Webhook.site | RequestBin | Beeceptor |
|---|---|---|---|---|
| Instant webhook URL, no account | Yes | Yes | Yes | Yes |
| Full payload inspection | Headers, body, query, path | Headers, body, query | Headers, body, query | Headers, body, query |
| Sample webhook library | Yes, 500 plus providers | No | No | No |
| Forward to localhost | Yes, through the Hookdeck CLI | No | No | Yes, built-in tunneling |
| Custom mock responses | No | Yes | No | Yes, full mock server |
| Free tier limit | 10,000 events per month | 100 requests per URL | 100 requests in the UI | 50 requests per day |
| Path to production | Yes, Event Gateway | No | No, funnels to Pipedream | No |
The free-tier arithmetic favors Inspect for sustained debugging. Ten thousand events a month is 100 times the 100 requests webhook.site allows per free URL, and 200 times the 50 requests a day Beeceptor allows on its free tier, which works out to about 1,500 a month. Webhook.site lets you create a new URL when one fills up, so the comparison is not quite apples to apples, but the friction of rotating URLs every 100 requests is real when you are deep in a debugging session.
RequestBin, the original temporary-bin inspector now owned by Pipedream, is still the fastest tool for a single one-off check, and its history is limited to the last 100 requests in the UI with SQL access to 7 days.
The one capability where Inspect clearly loses is custom mock responses. Webhook.site and Beeceptor let you configure the status code, headers, and body your URL returns, which is how you test whether a provider retries correctly after a 500 error or a timeout. Inspect returns a basic synchronous response and cannot simulate those failure modes, so if your test plan needs a provider to react to a specific error, pair Inspect with Beeceptor or webhook.site for that one case.
That is a narrow gap, and for most debugging work the sample library and CLI matter more.
When Should You Graduate from Inspect to Event Gateway?
You should graduate from Inspect to the Hookdeck Event Gateway when the webhooks you are testing become webhooks you depend on. Inspect answers the question of what a provider sends, and the Event Gateway answers the question of what happens when delivery fails, spikes, or needs to reach three services at once. The gateway adds durable queueing, automatic retries with configurable backoff, filtering, transformations, rate limiting, and full-text search across event history.
Every delivery attempt is logged with its request and response, so a failure in production is a searchable record instead of a guess.
The graduation path is deliberately staged, and each stage reuses the work of the one before it. Inspect gives you the URL and the payload, the CLI brings those events to your local server, and the Event Gateway takes the same sources, the same provider samples, and the same observability surface into production. Nothing you configured during testing gets thrown away, which is the opposite of the usual story, where the inspection tool and the production tool are two different products that never meet.
| Stage | What you do | What it adds over the previous stage |
|---|---|---|
| 1. Inspect | Open inspect.hookdeck.com and watch payloads arrive | Instant URL, full payload view, 500 plus provider samples |
| 2. CLI | Run hookdeck listen 3000 to forward events to localhost | Replay, terminal inspection, filtering, local debugging |
| 3. Event Gateway | Promote the source into a connection with destinations | Queues, retries, transformations, rate limits, search, alerting |
Durable execution is the concept underneath that third stage, and it is worth understanding before your first production incident. A durable workflow survives restarts, retries failed steps instead of losing them, and keeps a record of what happened, which is exactly what the Event Gateway provides for webhooks. If that pattern interests you, the guide on how to use Inngest explains the same idea from the application side, where functions checkpoint their progress instead of starting over.
Inspect is the inspection surface for that world, and the gateway is the runtime.
What Are Hookdeck Inspect's Limits?
Hookdeck Inspect has real limits, and knowing them before you build around it saves an unpleasant surprise later. The most important one is the absence of custom mock responses: you cannot configure a specific status code, header set, or response body for incoming requests, so testing how a provider handles a 500 error or a timeout needs a different tool. Webhook.site and Beeceptor both cover that case, and pairing them with Inspect for a single failure-path test is a reasonable workflow.
The free tier limits are the second constraint. Three-day retention and 10,000 events a month are generous for development, but they are not a production archive, and the dashboard locks when you exceed the event allowance until you upgrade or the billing period resets. There is also no self-hosted option, which matters for teams with data-sovereignty requirements: webhook.site and webhook-tester both offer open-source self-hosting under the MIT license, while Inspect runs only on Hookdeck's infrastructure.
The documentation also notes two smaller gaps: Hookdeck does not support debouncing events, and multipart form-data attachments become malformed, because attachments are not supported.
None of those limits disqualifies Inspect for its intended job, which is inspecting and debugging webhooks during development. They matter when the job changes: archiving months of payloads, simulating provider error handling, or running the inspector inside your own network. Judge the tool against the job you actually have, and it is easy to see where it fits and where a different inspector belongs.
Who Should Use Hookdeck Inspect, and Who Should Skip It?
Hookdeck Inspect is the right tool for a developer integrating a new webhook provider, a team debugging a failing delivery, or anyone letting an AI agent build a webhook handler from a real payload. It is also the right starting point for a team that expects to run webhooks in production eventually, because the inspection workflow and the production workflow are the same product. If your day involves Stripe, Shopify, GitHub, or Twilio events, and you want to see the payload before you write the parser, Inspect is the shortest path to that view.
Skip Inspect when your primary need is mocking rather than inspecting. If you need to return custom responses, simulate errors, or stub an entire provider API, Beeceptor is built for that job, and webhook.site covers the simpler version of it. Skip it as well when you need to self-host the inspector, or when a single 30-second check is all you need and any temporary bin will do.
The tool earns its place through the library, the CLI, and the path to production, and if you need none of those three, the simplest bin available is the honest choice.
The broader lesson is that webhook testing is not one tool but a small workflow: inspect the real payload, forward it to your local server, replay it until the handler is right, and promote the same setup to production when you ship. Hookdeck Inspect covers the first step better than any other free tool, and it is the only inspector in its class that carries you through all four steps without switching products. Start there, and let the limits decide when you need something else.
Sources
Hookdeck, Best Webhook Testing Tools for Inspecting and Debugging Webhooks, hookdeck.com, updated November 2026. Hookdeck, RequestBin Alternatives for Testing Webhooks, hookdeck.com, updated November 2026. Hookdeck, Hookdeck Basics, Event Gateway documentation, hookdeck.com, accessed November 5, 2026.
Hookdeck, Event Gateway Pricing, hookdeck.com, accessed November 5, 2026. seosandwitch.com, 10 Best Webhook Testing Tools in 2026, accessed November 5, 2026. reform.app, Top Webhook Testing Tools for Form Integrations, accessed November 5, 2026.
Frequently Asked Questions
Is Hookdeck Inspect really free?
Yes. Hookdeck Inspect is free to use with no account required, and creating a free Hookdeck account unlocks the Developer plan with 10,000 events a month and 3-day retention. Paid plans start at 39 dollars a month for the Team plan, and they add retention, users, and SLAs rather than more included events.
Do I need an account to test webhooks with Hookdeck Inspect?
No. Open inspect.hookdeck.com and you immediately get a unique webhook URL with no signup and no credit card. A free account is worth creating when you want event history beyond the browser session, a shared workspace for teammates, and the full 10,000-event monthly allowance.
Can I send mock Stripe webhooks with Hookdeck Inspect?
Yes. The built-in Webhook Library holds realistic sample payloads from more than 500 providers, including Stripe checkout.session.completed, Shopify orders/create, GitHub push, and Twilio inbound SMS. Pick a provider and event type, and Inspect fires the mock payload at your source URL or local server, with no provider account to configure first.
How is Hookdeck Inspect different from webhook.site?
Both give you an instant URL with no account, but Inspect adds a 500-plus provider sample library, forwarding to localhost through the Hookdeck CLI, and a path to production through the Event Gateway. Webhook.site answers with custom mock responses and a cleaner one-off experience, which Inspect does not offer. Choose Inspect for sustained debugging and webhook.site for a quick check or failure simulation.
Can I use Hookdeck Inspect with Claude Code?
Yes. Share your Inspect URL with Claude Code or Codex, and the agent can read requests as they arrive and use the payload to build your handler, with no MCP server or skills setup required. The Hookdeck CLI also ships an MCP server and agent skills for deeper integration, and delivery timeouts of up to 15 minutes cover long-running agent work.

