Safe testing boundaries
WebhookTest.net is an anonymous debugging tool, not a production secret store. The random bucket URL is the access control: anyone who has it can use the bucket.
Updated August 3, 2026
There is no account login around a bucket. Anyone with the bucket ID can view captured requests, change the configured response, clear captures, or delete the bucket. Treat both the dashboard URL and webhook endpoint as secrets.
Do not put bucket URLs in public tickets, screenshots, analytics, or source control. Create a new bucket if a URL was shared outside the intended test group.
The dashboard stores and displays the incoming method, headers, query parameters, body, sender IP, and timestamp. It does not automatically redact the browser dashboard. Never submit production authorization headers, signing secrets, cookies, personal data, payment data, or confidential payloads.
The hosted MCP interface redacts sensitive-looking header and query values by default, but include_sensitive can reveal them. That convenience is not a substitute for using synthetic fixtures.
Custom responses can set an HTTP status, content type, body, up to 20 safe response headers, and a delay of at most 10 seconds. Server-managed and hop-by-hop headers such as Content-Length, Transfer-Encoding, Set-Cookie, and X-Accel-* are rejected.
Incoming request bodies are capped at 1 MiB. Rate limits and bucket limits reduce accidental or abusive load, but a public endpoint should still never be used as a production processor.
Provider labs use fake signatures and fake identifiers. Real signature verification requires the unmodified raw request body and a secret or public key held by your application. Do not upload the verifier secret to the test bucket.
Do not place vulnerability details, bucket URLs, captured secrets, or exploit information in a public channel.