Outbound Webhook Tester & Debugger
Dispatch test webhooks to your receivers, sign payloads with HMAC-SHA256 secret keys, and measure delivery latency and response codes.
Understanding Webhooks and HMAC Signature Verification
📌 On this page
1. What webhooks are and why they matter
A webhook is a server-to-server HTTP callback: instead of your application repeatedly polling a service to ask "has anything happened yet?", the service pushes an HTTP request to your specified URL the instant an event occurs (an order is placed, a payment succeeds, a code push lands). This is dramatically more efficient than polling and is the standard integration pattern for WooCommerce order events, Stripe payment confirmations, GitHub repository events, and countless SaaS platform notifications.
2. How HMAC signatures prevent forged requests
Since a webhook receiver is a public URL, anyone who discovers it could send fake requests pretending to be the real event source. HMAC-SHA256 signing solves this: the sender and receiver share a secret key known only to them. The sender computes a cryptographic hash of the request body using that secret and includes it in a header (commonly X-Hub-Signature-256). The receiver recomputes the same hash independently and compares — if they match, the payload is authentically from the sender and wasn't altered in transit; if they don't match, the request should be rejected.
3. Implementing signature verification correctly
Two implementation details matter a great deal in practice: first, always hash the raw, unmodified request body bytes — parsing the JSON and re-serializing it before hashing will almost always produce a different signature and cause valid requests to be rejected. Second, use a constant-time comparison function (like Node's crypto.timingSafeEqual) rather than a simple string equality check when comparing signatures, since naive string comparison can leak timing information that a determined attacker could exploit to guess the correct signature byte-by-byte.
4. What a well-behaved webhook receiver looks like
Webhook senders generally expect a fast 2xx response (200 or 204) within a few seconds — most providers will consider the delivery failed and retry if your endpoint takes too long or returns a 4xx/5xx status. The correct pattern is to validate the signature, quickly persist or queue the payload for processing, and respond immediately — then handle the actual business logic (sending emails, updating records, calling other APIs) asynchronously in a background job. An endpoint that does all its processing synchronously before responding is the most common cause of webhook timeout failures at scale.
5. Why the preset payloads matter for realistic testing
The WooCommerce, Stripe, GitHub, and Slack presets loaded by this tool mirror the actual field structure and naming conventions those platforms use in production, which matters because testing against a payload shape that doesn't match reality can pass locally while still failing against the real provider. Use these presets as a starting point, then customize field values (or the structure itself, for providers not listed) to match the specific event type and edge cases you need to verify your receiver handles correctly.
6. SSRF protection: why it's non-negotiable here
Because this tool makes a genuine outbound request on the user's behalf, without strict URL filtering it could be abused to probe or attack internal network infrastructure (localhost services, private IP ranges, cloud provider metadata endpoints that can leak credentials) from Nimbica's own servers. Every destination URL is checked against an SSRF allowlist before any request is dispatched — this is the same protection pattern applied across every live-fetch tool on this platform.
Frequently Asked Questions
How does HMAC-SHA256 signature verification work for webhooks?
HMAC (Hash-based Message Authentication Code) uses a shared secret key and the raw webhook request body to generate a cryptographic hash. The receiving server recalculates the hash and compares it against the signature header to verify that the payload was not tampered with and originated from an authentic sender.
How does this tool enforce SSRF security when sending webhooks?
Outbound requests are strictly filtered through an SSRF verification layer that blocks internal IP ranges (10.x, 192.168.x, 172.16-31.x), localhost, loopback addresses (127.0.0.1, ::1), and cloud metadata endpoints (169.254.169.254).
What are standard webhook response expectations?
Webhook endpoints should respond immediately with an HTTP 200 or 204 status code in under 2 seconds. Long processing tasks should be pushed onto an asynchronous background queue (like Redis or Celery) to prevent timeout failures.
Can I test WooCommerce or Stripe webhook consumers with this tool?
Yes. Select the WooCommerce or Stripe preset to load realistic event payloads and pass your webhook secret to compute authentic signature headers.
Does this tool actually deliver the request over the network, or simulate it?
It performs a genuine outbound HTTP request from the server to your specified destination URL — the status code, response headers, response body, and delivery latency shown are all real, measured values from your actual endpoint, not simulated or mocked. This is the same reason strict SSRF protection is required: a tool that makes real outbound requests on a user's behalf must prevent that request from being pointed at internal infrastructure.
Why does the HMAC signature use my raw payload body, not the JSON-parsed object?
HMAC signature verification must be computed over the exact bytes that were transmitted, not a re-serialized version of the parsed data — because JSON re-serialization can reorder keys, change whitespace, or alter number formatting in ways that would produce a different signature than the original. This tool signs the literal raw request body text, exactly matching how real webhook providers like GitHub, Stripe, and WooCommerce compute their signatures, so testing your verification logic here reflects real-world behavior.
My receiving endpoint times out or never responds — what should I check?
First confirm your endpoint is publicly reachable (not behind a firewall, VPN, or localhost-only binding) — this tool cannot reach private or internal addresses by design. If the URL is public, check that your endpoint isn't blocked waiting on a slow synchronous operation (database write, external API call) before responding; webhook receivers should acknowledge receipt immediately and process the payload asynchronously. This tool's own request times out after 12 seconds, matching typical real-world webhook provider timeout behavior.