Decide What the Webhook Test Must Prove
A useful webhook test starts with a narrow question. Are you checking that a sender can reach a URL, that JSON is serialized correctly, that required headers exist, or that the sender retries after an error? Each question needs a different assertion.
Use a temporary request inspector to observe the HTTP boundary without application code. It shows what arrived and what response was returned. It does not prove that your production signature validation, queue, database, or business logic is correct.
Use synthetic identifiers and redacted values. A reproducible test request should be safe to store in source control or share with a teammate after the temporary endpoint ID has been removed.
Send a Baseline JSON Webhook with cURL
Create an endpoint and replace YOUR_BUCKET_ID in the command below. The explicit method, content type, test event header, and compact JSON body make every part of the request visible.
Run the command, open the captured request, and check the method, Content-Type, X-Test-Event value, and body. If they match, you have a stable baseline before adding authentication or provider-specific fields.
Use single quotes around JSON in shells that support them. Windows command quoting differs, so PowerShell users may prefer Invoke-RestMethod or a JSON file passed to curl.
curl --request POST 'https://webhooktest.net/webhook/YOUR_BUCKET_ID' \
--header 'Content-Type: application/json' \
--header 'X-Test-Event: order.created' \
--data '{"id":"evt_test_123","status":"created"}'- Replace only the bucket ID before the first run
- Keep the sample event ID synthetic
- Confirm header names and values in the inspector
- Save the command as a repeatable fixture after removing the temporary URL
Exercise Query Parameters and Other Methods
Webhook providers sometimes include a verification token or routing value in the query string. Add test query values deliberately and confirm that decoding preserves spaces, symbols, repeated keys, and empty values as expected.
Change the request method when testing a generic callback or API client. A captured PUT, PATCH, GET, or DELETE request should be handled according to the contract rather than silently treated as POST.
Use verbose curl output when the request never appears. It exposes DNS, TLS, connection, redirect, and response details without changing the request inspector.
curl --verbose --request POST \
'https://webhooktest.net/webhook/YOUR_BUCKET_ID?source=checkout&attempt=1' \
--header 'Content-Type: application/json' \
--data '{"ok":true}'Build the Same Request in Postman
Create a Postman request, choose POST, and paste the temporary endpoint URL. Add Content-Type application/json and any test event headers in the Headers tab. In Body, choose raw and JSON, then paste the same synthetic payload used by cURL.
Store the base endpoint in a Postman environment variable when several requests share it. Keep the temporary bucket ID out of published collections, screenshots, and long-lived team environments.
Send the request and compare Postman Console evidence with the captured request. If values differ, check scripts, variable resolution, automatic headers, proxy settings, and JSON formatting before blaming the webhook receiver.
- Set the method and URL explicitly
- Use raw JSON rather than form data unless the provider contract requires it
- Inspect resolved variables before sending
- Compare the Postman Console request with the server-side capture
Test Responses, Retries, and the Production Handoff
Configure the temporary endpoint to return the success response your sender expects. Then test deliberate 400, 429, and 500 responses one at a time and record whether the sender retries, how long it waits, and whether it reuses a stable event ID.
Do not infer retry behavior from one provider and apply it to another. Confirm timeout, accepted status codes, retry schedule, and delivery history in the provider documentation.
When the HTTP contract is understood, move the same fixtures into automated tests for your own receiver. Add signature verification with the raw body, idempotency, payload limits, fast acknowledgement, queued processing, and safe operational logging.
- Prove the normal 2xx delivery path first
- Test one failure status at a time
- Record retry timing and duplicate identifiers
- Convert safe requests into automated fixtures
- Remove the temporary endpoint from provider configuration
Common questions
Frequently asked questions
- How do I test a webhook with cURL?
- Create a temporary endpoint and send an HTTP request to it with curl. Set the method, Content-Type header, and JSON body explicitly, then compare the captured request with the command you sent.
- How do I test a webhook in Postman?
- Create a request, choose the HTTP method, paste the temporary endpoint URL, add required headers, select a raw JSON body, and send it. Use Postman variables for reusable endpoint values and test data.
- Which response code should a webhook return?
- Most senders treat a 2xx response as successful delivery. Use controlled 400, 401, 429, and 500 responses only in a test environment to check validation, authentication, rate-limit, and retry behavior.
- Can I test GET, PUT, PATCH, and DELETE webhooks?
- Yes. The temporary endpoint accepts common HTTP methods. Testing more than POST is useful for generic callbacks and API clients, although many webhook providers deliver events with POST.
Primary sources
Official references
Try it with a real request
Turn the guide into a test.
Open a temporary endpoint, send your payload, and inspect exactly what arrived.
Open the tester