Understanding Webhook Request Structures
A webhook is an automated message sent by an application when an event occurs. Unlike standard API requests initiated by a client to pull data from a server, webhooks push data from a source system to a destination URL. To process these incoming events reliably, developers must understand the exact structure of the incoming HTTP request.
A typical webhook request consists of an HTTP method, a set of headers containing metadata, and a payload body containing the event details. Inspecting these components helps identify the payload format, locate security tokens, and diagnose integration issues.
The Role of Headers in Webhook Communication
HTTP headers provide essential context about the webhook payload and its origin. They communicate the media type of the body, the identity of the sending service, and security details.
When inspecting a webhook request, headers are evaluated line by line. The tool accepts up to 200 non-empty header lines, with a maximum limit of 100,000 characters. Each header must follow the standard format:
Name: value
If a line does not conform to this structure, the tool displays the error message: Header line ‹line› is invalid. Use Name: value.. If the input exceeds the allowed limits, the tool returns either The headers are too long for this tool. Remove unrelated or repeated values. or There are too many header lines. Keep the request to 200 headers or fewer..
Webhook Body Formats and Parsing Rules
The request body contains the actual event data sent by the webhook provider. Webhook payloads are commonly transmitted in one of two formats: JSON or URL-encoded form data.
The tool automatically detects these formats and processes them for readability:
- JSON: Parsed using
JSON.parse. This process formats the payload but reorders the fields, meaning the original whitespace and field arrangement are lost. If the body resembles JSON but contains syntax errors, the tool displays:The body looks like JSON but could not be parsed.. - URL-encoded form data: Decoded and formatted into a readable structure. If the payload contains an invalid percent-encoding sequence, the tool displays:
The form body contains an incomplete percent escape.. - Other formats: Plain text, XML, multipart, or binary payloads remain as raw plain text without formatting.
The maximum supported body size is 1,000,000 characters. Exceeding this limit triggers the error: The body is too long for this tool. Keep it under 1,000,000 characters.. If the body is empty, the output displays (empty body). If both the headers and body fields are empty when running an inspection, the tool returns: Paste at least one header or a request body first..
Webhook Signatures and Timestamps
To prevent unauthorized parties from spoofing webhook events, providers often sign the payload. They include cryptographic signatures and timestamps in the HTTP headers.
The tool scans the pasted headers for common naming patterns associated with security, such as signature, hmac, digest, and typical timestamp names.
- If a matching header is found, it is displayed under the signature fields section.
- If no matching header is detected, the tool displays:
No common signature or webhook timestamp header was found..
Inspecting vs. Verifying Webhook Authenticity
It is critical to distinguish between identifying a signature header and verifying its authenticity. The tool only surfaces the signature and timestamp fields for inspection. It does not calculate HMAC values, execute cryptographic algorithms, verify payload bytes, check secrets, evaluate replay windows, or perform provider-specific verification.
Finding a signature field does not prove the request is authentic. Real verification requires executing the sender's specific signing rules using your secret key and the exact, unaltered raw bytes of the incoming request body.
Local Testing with cURL
Once a webhook request is inspected, testing how your local application handles the payload is a common next step. The tool automatically generates a copyable shell-quoted cURL command designed for local testing.
This generated command is fixed to target:
http://localhost:3000/webhooks
By copying this command into a terminal, developers can replay the exact method, headers, and body of the captured webhook directly against their local development server.
Best Practices for Capturing and Inspecting Webhooks
When debugging webhooks, always capture the exact raw body before any server-side parsing or middleware alters the payload. Webhook signatures are highly sensitive to character changes. Even minor modifications, such as normalizing whitespace, reordering JSON keys, or converting line endings, will alter the raw byte sequence and cause cryptographic signature verification to fail.
Privacy and Data Processing
Your pasted request stays in your browser. BroBroGo does not upload or save it. All parsing, formatting, and cURL command generation occur locally within the client browser session.
Frequently Asked Questions
Which webhook body formats can I inspect?
JSON and URL-encoded form bodies are detected and formatted. Other bodies stay as plain text so the tool does not guess at XML, multipart or binary content.
Does finding a signature field prove the request is authentic?
No. The tool only surfaces signature and related timestamp headers. Real verification needs the sender’s exact signing rules, secret or public key, and the original request bytes.
Can this page receive a live webhook callback?
No. Paste a captured request here for inspection. The page does not create a public endpoint, receive callbacks or send the generated test request.