Skip to content
newThe webhook.co MCP server is live — turn any webhook into an agent event. Read the docs
test locally

Test Zendesk webhooks locally

Zendesk will happily send you real ticket events, but it also ships a Test webhook panel that fires a sample request on demand. Here's what's specific to Zendesk once your local endpoint is listening.

The loop

Create an endpoint and it prints a permanent ingest URL. Everything sent there is captured whole — headers, body, the exact bytes — before anything else happens. Stream those events to a port on your machine, and replay any one of them as often as you like while you fix the handler. Forwarding runs from your own machine, so it isn't a billable delivery.

wbhkzendesk
$ wbhk endpoints create zendesk-dev
https://wbhk.my/whep_…
$ wbhk listen <endpoint-id> --forward http://localhost:3000/webhooks
$ wbhk replay <event-id> --forward http://localhost:3000/webhooks

What's different about Zendesk

Zendesk creates the webhook as a standalone object, and the first thing the create flow asks is the connection method — Zendesk events, or Trigger or Automation. That choice decides everything after it. Pick Zendesk events and you select event types from a dropdown. Pick Trigger or Automation and the webhook is driven by a business rule instead, and its request payload or URL parameters can't exceed 16,000 characters. The names are URN-shaped rather than bare verbs, too: a fixed zen:event-type: prefix in front of every one.

Where the URL goes

In Admin Center, click Apps and integrations in the sidebar, then select Webhooks, then Webhooks, and click Create webhook. Choose the connection method — Zendesk events, or Trigger or Automation — and click Next. Then fill in a Name, a Description, and the Endpoint URL. HTTPS isn't required, but custom headers only work on a secure HTTPS endpoint, so paste the https form of your ingest URL.

Zendesk ships its own: find the webhook in the list, open the options menu on its row, and click Test webhook. Select an event to test — that's a sample request — fill in the request body, parameters or headers, and click Send test. The response shows in the panel below. The same button appears while you're creating or editing a webhook, and the API equivalent is POST /api/v2/webhooks/test.

What Zendesk sends

Every event type is a URN: the fixed prefix zen:event-type: followed by a dot-separated resource and action pair. Copy them exactly — the prefix is part of the name, and Zendesk's own index page renders a few entries with a slash where the per-resource reference pages use a colon.

  • zen:event-type:ticket.created
  • zen:event-type:ticket.comment_added
  • zen:event-type:ticket.status_changed
  • zen:event-type:ticket.priority_changed
  • zen:event-type:user.created
  • zen:event-type:organization.created

Worth knowing first

Retries name only three codes

The docs name only three retryable statuses. A 409 is retried up to three times; a 429 or 503 is retried only if the response carries a retry-after header valued at under 60 seconds. Requests that hit the timeout are retried up to five times. Consecutive failures won't deactivate the webhook, though.

Twelve seconds, and not adjustable

Webhook requests have a 12-second timeout, and the timeout period is not adjustable. A slow receiver doesn't fail quietly — it lands in the activity log as Failed: 504 Gateway Timeout, which is Zendesk describing your endpoint rather than its own. Pausing a forwarded request on a breakpoint reproduces this quickly.

The circuit breaker cuts you off

If 70% of a webhook's requests error inside a five-minute period, or it takes more than 1,000 error responses in five minutes, the circuit breaker fires and blocks sending for five seconds. Attempts during the pause are logged with a status of circuit broken until a request succeeds. It won't fire below 100 requests per five minutes.

Duplicates and ordering are yours

Delivery is best effort: the same action can invoke a webhook more than once, and under some conditions — the circuit breaker firing, for one — an event may not be delivered at all. Make handlers idempotent. Because webhook jobs are queued and run independently, the order they execute in isn't promised.

Custom headers need HTTPS

Secure HTTP is recommended rather than required for the endpoint URL, but custom headers only work on an HTTPS endpoint — so if you're testing header-based auth, an insecure URL won't get you there. Separately, a webhook connected to a trigger or automation caps its request payload or URL parameters at 16,000 characters.

Signature checking is handled for you once the secret is registered — you can also check a captured signature by hand in the signature verifier.

Zendesk webhooks: common questions

Can I test a Zendesk webhook without waiting for a real ticket event?

Yes. Admin Center has a Test webhook option on each webhook's row, and the same button appears while you create or edit one. You pick a sample event, fill in the request body, parameters or headers, send it, and read the response inline.

Why did my Zendesk webhook fire twice for one ticket update?

Zendesk makes a best effort to deliver each action a single time, which means the same action can invoke a webhook multiple times. Build the handler to be idempotent, keyed on something stable in the payload, and treat a repeat as expected rather than as a bug.

How long does Zendesk wait for my endpoint to respond?

Twelve seconds, and the timeout period is not adjustable. Anything slower is recorded in the activity log as Failed: 504 Gateway Timeout. Requests that time out are retried up to five times, which is a longer allowance than most error statuses get.

Does Zendesk require an HTTPS endpoint URL?

No. Secure HTTP is recommended but not required for the endpoint URL. There is one catch worth knowing: custom headers only work when the endpoint URL is HTTPS, so an insecure URL quietly limits what you can configure on the webhook itself.

How do I verify that a request really came from Zendesk?

Zendesk sends optional signature headers named X-Zendesk-Webhook-Signature and X-Zendesk-Webhook-Signature-Timestamp. The signature is the base64 encoding of an HMAC SHA256 over the timestamp concatenated with the body. Compute the same value with your signing secret and compare it before acting on the payload.

What do Zendesk webhook event names look like?

Every event type is a URN with the fixed prefix zen:event-type: followed by a dot separated resource and action, such as zen:event-type:ticket.created. Copy the strings exactly from the per resource reference pages; the prefix is part of the name, not documentation shorthand.

Point a webhook at it. Watch it land.

Start free: a permanent URL, full inspection, one-command replay — and outbound delivery, because every feature is on every plan. Move up when you need more events.