🔗 Webhook Tester - Test HTTP webhook endpoints

Webhook Tester sends controlled HTTP requests to public callback URLs so you can test webhook receivers, API endpoints, and integration callbacks before connecting a live service. Use it as an online webhook tester for POST JSON payloads, signed event callbacks, status-code checks, and response header inspection.

Webhooks are usually plain HTTP requests: a provider sends an event payload to your URL, and your server replies with a status code that tells the provider whether delivery succeeded. This tester follows the request/response model defined by RFC 9110 HTTP Semantics, accepts JSON bodies described by RFC 8259, and is useful when comparing vendor payloads to event formats such as CloudEvents or W3C WebSub.

Common webhook test cases:

• Send a POST request with Content-Type: application/json to verify a callback URL accepts events.
• Replay a payment, deployment, alerting, or CRM notification payload against a development endpoint.
• Check whether your receiver returns the expected 2xx, 4xx, or 5xx status code.
• Debug custom headers such as Authorization, X-API-Key, correlation IDs, and idempotency keys.
• Measure response time and inspect response headers when a third-party integration reports delivery failures.

Supported request shapes:

• POST: The most common webhook delivery method for event notifications and JSON bodies.
• PUT: Useful for full resource replacement tests when an API models callbacks as resources.
• PATCH: Useful for partial update endpoints and webhook-like change notifications.
• GET: Useful for health checks, verification callbacks, and endpoint reachability checks.
• DELETE: Useful when testing cleanup callbacks or API endpoints that remove a resource.

Example: a typical JSON webhook test sends {"event":"order.paid","id":"evt_123"} with Content-Type: application/json. A healthy receiver normally returns a quick 200 OK, 202 Accepted, or another documented success code; retries and duplicate event handling should be tested separately with your provider's rules.

Authentication and signatures:

• Bearer-token headers follow the pattern documented in RFC 6750.
• HMAC-style webhook signatures should be generated exactly as the provider documents, including timestamp and raw-body rules.
• Standardized request signing is covered by RFC 9421 HTTP Message Signatures, though many webhook providers use custom schemes.

Security and limits: This tool sends requests from the Online Cyber Tools server, not from your browser. Private, local, and reserved network targets are blocked to reduce SSRF risk, but you should still avoid production secrets, live customer data, destructive endpoints, and one-time tokens. Some providers also require fixed source IPs, mTLS, replay windows, or proprietary signature headers that this generic tester cannot fully emulate.