Webhook Guides

Webhook Test URL

A webhook test URL is a public HTTP endpoint you can paste into a provider dashboard or call with cURL to see what the sender actually posts. It is the quickest way to validate method, path, query string, headers, content type, and request body before building a permanent receiver.

FastHook gives you a test URL through a source or request bin. When the test becomes real traffic, the same pattern can route events to HTTP, Slack, Google Sheets, mock receivers, local CLI destinations, or any other FastHook destination with retry and replay evidence.

When to use a webhook test URL

  • You need to confirm that Stripe, GitHub, Shopify, Twilio, or another sender can reach a public URL.
  • You want to inspect the exact payload and headers a provider sends.
  • You are testing a new webhook integration before pointing it at production code.
  • You need a safe endpoint for cURL, QA, support, or documentation examples.
  • You want request evidence before deciding which destination should receive the event.

Create the test URL

In FastHook, the provider-facing test URL is a source URL. Use a short-lived request bin for disposable payload discovery, or create a source when the test should become a long-lived integration.

Create webhook test source
curl -X POST "https://api.fasthook.io/v1/sources" \
  -H "Authorization: Bearer $FASTHOOK_API_KEY" \
  -H "x-team-id: $FASTHOOK_TEAM_ID" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Webhook test URL",
    "type": "WEBHOOK",
    "config": {
      "auth_type": null,
      "allowed_http_methods": ["POST"]
    }
  }'

Send a test request

After the source returns a public URL, send a simple payload. The first test should prove connectivity and request capture before you add signatures, filters, transformations, or destination delivery.

Send test webhook
curl -X POST "https://hook-xxxxxx.fasthook.io/" \
  -H "Content-Type: application/json" \
  -H "X-Test-Run: webhook-test-url" \
  -d '{
    "id": "evt_test_url_001",
    "type": "test.created",
    "data": {
      "source": "webhook-test-url",
      "ok": true
    }
  }'

What to inspect

EvidenceWhy it matters
Method, path, and query stringConfirms the sender is calling the expected endpoint shape.
Headers and content typeShows signature headers, event type headers, and encoding behavior.
Raw or parsed bodyProves the payload shape before receiver code depends on it.
Source statusSeparates accepted requests from auth, method, or validation rejections.
Event and attempt recordsShows what happened after capture when the test is routed to a destination.

Test URL vs receiver URL

A webhook test URL is the provider-facing URL. A receiver URL is the app endpoint that eventually handles the routed event. Keeping those separate lets you keep the provider configuration stable while changing destinations, testing locally, adding filters, or replaying failed events.

  • Webhook URL explains source URLs, destination URLs, paths, and auth.
  • Webhook test covers the broader end-to-end test workflow.
  • Webhook tester covers payload, mock, local, retry, and replay tests.

Move from test URL to production route

  1. Create a permanent FastHook source for the provider and environment.
  2. Add source authentication or provider signature validation where the provider supports it.
  3. Create destinations for HTTP receivers, Slack, Google Sheets, mock APIs, or local CLI delivery.
  4. Add connection filters so only the intended events are delivered to each destination.
  5. Inspect request, event, and attempt evidence before turning on retry and replay workflows.

Related guides