Core Features

Receiving HTTP Requests

Send JSON, text or form data to your receiving URL. Capture paths, repeated query parameters and headers, then interpret the HTTP response alongside history.

On this page

Send a request

Use an active endpoint and copy its receiving URL. Server-to-server HTTP does not require a WebhookKit account or management token.

In a Bash-compatible shell with cURL installed, set WEBHOOK_URL to the receiving URL copied from your endpoint. Replace <YOUR_RECEIVING_URL> including the angle brackets, without a trailing slash; keep the single quotes. Reuse that variable for the examples on this page.

Bash / cURL

WEBHOOK_URL='<YOUR_RECEIVING_URL>'

curl -i --request POST "${WEBHOOK_URL}/orders?source=docs" \
  --header 'Content-Type: application/json' \
  --header 'X-Demo-Event: order.created' \
  --data '{"event":"order.created","order":{"id":"order_demo_001","status":"created"}}'

Expect a POST in history with the JSON body and demo header. The default response is HTTP 200 with an empty body.

Paths and query parameters

Bash / cURL

curl --include "${WEBHOOK_URL}/orders?source=docs&tag=first&tag=second"

Expect a GET with path /orders. The Query tab preserves both tag values as well as source=docs. Keep the endpoint token intact when appending paths. Set Content-Type to describe your body; headers are captured alongside it.

Send different payloads

After setting WEBHOOK_URL, send any of these synthetic payloads. The inspector preserves raw bytes; it does not validate JSON schemas or verify webhook signatures.

Plain text

Bash / cURL

curl --include "${WEBHOOK_URL}/notes" \
  --header 'Content-Type: text/plain' \
  --data 'Synthetic delivery test'

URL-encoded form

Bash / cURL

curl --include "${WEBHOOK_URL}/forms" \
  --data-urlencode 'event=order.created' \
  --data-urlencode 'note=synthetic test'

Multipart form

Bash / cURL

curl --include "${WEBHOOK_URL}/uploads" \
  --form 'note=synthetic test'

Multipart content is captured as raw bytes, including boundaries. File-part extraction is not provided.

Valid and invalid JSON can both be inspected. For binary files, method behavior and body limits, see HTTP methods and payloads.

Forward to localhost

When localhost forwarding is enabled, signed-in accounts can run the WebhookKit CLI on the same host as their application. Install the binary from its release archive, verify SHA256SUMS, and add it to PATH.

Bash / cURL

webhookkit listen 3000
webhookkit listen http://localhost:3000/webhooks --manual

Approve the matching code in your browser and choose your endpoint. The Localhost panel shows the command for that endpoint, its connection, automatic/manual mode and Disconnect. Use “Send to localhost” in the inspector for older requests. Requests from an offline period are never sent automatically after reconnect.

WebhookKit still responds immediately to the original sender. Local HTTP status and time to response headers are separate results reported by your CLI. Local responses cannot answer synchronous verification challenges. Captured Authorization, Cookie and signature headers reach your local app; signatures tied to the original URL or an old timestamp may fail. UNKNOWN may have produced an effect: deliberately sending again can duplicate it. Local response bodies and headers are not collected.

Read the response

A saved custom 4xx or 5xx response can accompany a successful capture. If a sender reports a timeout or service error, check history before resending: persistence may already have succeeded and a resend can create a duplicate.

The custom response applies endpoint-wide to subsequent requests after saving. Browser requests can involve CORS preflight and framework OPTIONS handling; a successful server-to-server cURL test does not establish browser cross-origin permission.

For 410, 413 or 429, compare the sender’s exact response with history and your saved response configuration. Follow Common Issues before retrying.