Datadog Webhook Tester — Test & Inspect Datadog Webhooks Online

If you are wiring up Datadog webhooks, the first question is always the same: what does Datadog actually send? The docs show an idealised payload, but the real request — its headers and the exact JSON shape — is what your handler has to parse. A Datadog webhook tester gives you a public URL that captures those real requests so you can read every byte before you write any code.

Get a free Datadog webhook tester URL

The fastest way is our free Webhook Bin — a no-code webhook tester that gives you an instant public URL and stores every request that hits it, headers and body included. No signup, no deploy:

1. Open the Webhook Bin and copy the URL it generates for you.
2. In Datadog → Integrations → Webhooks, add a webhook endpoint and paste that URL.
3. Trigger an event (see below) and watch the request land in the bin in real time.

Because the bin keeps the full request, you can inspect the headers, the Content-Type, and the complete payload — everything you need to build and verify a handler.

What a Datadog webhook looks like

Datadog delivers webhooks as an HTTP POST with a application/json body. Datadog webhooks are custom: you define the JSON payload yourself in the webhook's Payload field using template variables like $EVENT_TITLE, $EVENT_MSG and $ALERT_TYPE. So the shape is whatever you template — capturing a real fire shows you exactly what your template renders to.

A typical payload looks like this:

{
  "title": "[Triggered] CPU high on web-1",
  "body": "CPU is above 90%",
  "alert_type": "error",
  "event_id": "..."
}

Common Datadog events you will want to test:

• monitor alert
• monitor recovery
• monitor warning
• any event you route to the webhook

Securing the Datadog webhook

Datadog webhooks have no built-in cryptographic signature. Instead, you secure them with a shared secret you control: in the webhook configuration add a custom header (for example X-Webhook-Secret: <long-random-value>) under Headers, then reject any request to your endpoint that doesn't carry it. Because you also control the payload template, you can include a secret field in the body as well. Capturing a real request in a tester confirms your custom header and templated payload arrive exactly as configured.

You can sanity-check an HMAC implementation with the free HMAC signature verifier; for language-specific code and the common pitfalls, read verify a webhook signature.

From inspecting to receiving on localhost

A bin is perfect for seeing the payload. When you are ready to drive your local handler with real Datadog events — without deploying — forward them straight to localhost with the Webhook Relay agent. The full walkthrough is here: Receive Datadog webhooks on localhost.

That gives you a stable public URL that tunnels to your machine, so Datadog keeps delivering to the same endpoint while you iterate on localhost, no firewall changes or public IP required.

Test Datadog webhooks online in three steps

1. Capture — point Datadog at a Webhook Bin URL and inspect the real request.
2. Verify — confirm the request is authentic (see above).
3. Forward — when the shape is clear, receive Datadog webhooks on localhost and build your handler.

New to webhooks in general? Start with what is a webhook and how to test webhooks.

Ready to inspect your first Datadog event? Open a free Webhook Bin and paste the URL into Datadog.