Webhook Guides
Webhook Receiver Online
An online webhook receiver gives you a public URL that can accept provider callbacks, cURL tests, and internal HTTP events while showing exactly what arrived.
FastHook starts with that request-inbox workflow, then keeps the same traffic useful after testing by linking the captured request to routed events, destination attempts, retries, and replay.
What to inspect in the receiver
| Request evidence | Why it matters |
|---|---|
| Method, path, and query string | Confirms the sender used the expected endpoint and route. |
| Headers and content type | Shows signatures, event names, delivery ids, auth headers, and body format. |
| Raw payload body | Lets you compare provider data with the fixture your receiver expects. |
| Source auth result | Separates malformed traffic from valid webhook events. |
| Routed events and attempts | Proves what happened after the receiver accepted the request. |
Receive a webhook online
curl -X POST "https://hook-xxxxxx.fasthook.io/" \
-H "Content-Type: application/json" \
-H "X-Event-Type: order.created" \
-d '{
"id": "evt_receiver_001",
"type": "order.created",
"data": {
"order_id": "ord_102",
"total": 4900,
"currency": "USD"
}
}'Receiver vs tester vs debugger
These pages overlap, but the intent is different. Use an online receiver when the main job is collecting incoming HTTP requests and reading what the sender posted.
| Page | Best fit |
|---|---|
| Webhook receiver online | Create a URL, receive traffic, and inspect incoming requests. |
| Webhook inspector | Read captured headers, payloads, paths, query params, and source verification evidence. |
| Webhook tester | Exercise happy-path and failure-path webhook behavior with fixtures. |
| RequestBin | Use a temporary request-bin style inbox for quick capture. |
| Webhook debugger | Diagnose where accepted webhook traffic failed after routing or delivery. |
When a simple receiver is not enough
A basic receiver proves that a POST arrived. Production webhook work usually needs more evidence: whether the source accepted the request, which connection matched, what the downstream receiver returned, and whether a retry or replay is safe.
FastHook keeps the inbound request separate from downstream events and delivery attempts. That means you can start with online capture, then keep the same source URL for routing, local forwarding, Slack alerts, Google Sheets rows, HTTP destinations, retries, and incident recovery.
- Use source URLs for stable provider configuration.
- Inspect captured headers, paths, query params, and payloads before writing receiver code.
- Connect the source to mock, local, staging, or production destinations.
- Read destination response bodies before retrying failed events.
- Replay captured requests when filters, transformations, or destinations change.
Online receiver checklist
- Create a FastHook source URL for the sender or provider.
- Send a fixture request and inspect the captured method, headers, path, query, and body.
- Enable source authentication or provider signature verification before production traffic.
- Route accepted requests to one or more destinations through connections.
- Keep request, event, and attempt records available for debugging and replay.