Use cases · Webhook testing

See what the provider actually sent.

Integration not firing? Point the provider at Hook instead of your localhost, read the real request, then forward it to your service with the proxy once it looks right.

  • Any method: GET, POST, PUT, PATCH, DELETE and HEAD
  • JSON, form, text and JWS bodies shown readably, raw kept underneath
  • Copy as curl in the web app to replay a request locally
  • Proxy (Pro) forwards live traffic to your service while you watch
A webhook request inspected in Hook

Set it up in a minute. Three steps.

  1. Step 1

    Get an endpoint

    Try the throwaway one on gethook.app, or create a workspace in the app for one that keeps its history.

  2. Step 2

    Trigger the event

    Use the provider's test button or do the real thing.

  3. Step 3

    Inspect and replay

    Read headers, query and body; copy the request as curl to replay it against your own code.

terminal
curl -X POST https://gethook.app/workspace/{workspace_key}/test \
  -H "content-type: application/json" \
  -d '{"event":"payment.succeeded","amount":4200}'

Replace {workspace_key} with the key shown in the app. Fields like title and priority are explained in Publishing messages.

What people ask before they set it up.

How long are requests kept?

On the free plan the app shows the last 7 days; Pro keeps your history. The live endpoint on the homepage forgets requests after 15 minutes.

Can Hook send a custom response back to the provider?

No. Hook always answers 202 Accepted. If the provider needs a specific response, forward the request to your service with the proxy.

Compared with other tools for this job.

More uses for Hook.

Get the next request on your phone. Free to start.