Zendesk Webhooks
Zendesk webhooks turn your integration from a program that keeps asking into one that gets told. The interesting part is what happens after the request arrives.
What a Zendesk webhook is
You register an HTTPS endpoint you control. Zendesk sends it a JSON payload when something happens. That's it, conceptually, and everything else is detail.
There are two ways to make one fire, and the choice matters.
On the outbound call you can add basic auth, a bearer token or an API key header, so your endpoint can reject anything that's not from you. You can also enable signing, which is better, and covered below.
Why webhooks beat polling
Latency. Poll once a minute and your average delay is thirty seconds, with a worst case of sixty. For anything customer-visible that's the difference between an integration that feels alive and one that feels broken.
Cost. Polling spends your API rate limit asking a question whose answer is almost always nothing. On a busy account those requests compete with the ones you actually need.
Transitions, not states. A poll shows you the current state. A ticket that went Open, then Pending, then back to Open between two polls looks completely unchanged, and your integration silently missed two things that mattered.
Scaling shape. Polling cost grows with how much data you have. Webhook cost grows with how much actually happened. Those diverge fast.
One honest point in favour of polling: it's self-healing. If your consumer was down for an hour, the next poll catches up on its own. Webhooks don't come back. That single property is why the reconciliation sweep below isn't optional.
Verify the request
An endpoint on the public internet that acts on whatever is posted to it's a liability. Zendesk can sign webhook requests, and you should verify.
The mechanics are standard: a signature header containing an HMAC of the raw request body, plus a timestamp header. Compute the same HMAC with your shared secret, compare using a constant-time function rather than string equality, and reject anything whose timestamp is more than a few minutes old so a captured request can't be replayed at leisure.
Verify against the raw body bytes, before any JSON parsing or framework middleware reformats them. This trips up more people than the cryptography does.
One more habit worth adopting: treat the payload as a notification, not as truth. If the decision you're about to make matters, take the ticket ID and re-fetch the current state from the API. The payload describes a moment that has already passed.
Building a consumer that doesn't lose or double-process events
This is where integrations succeed or quietly rot. Five rules.
Answer fast, work later
Return 200 within a second or two, having done nothing except validate and enqueue. Do the real work off a queue. A handler that calls three APIs before responding will time out under load, and repeated failures can get your webhook deactivated entirely.
Be idempotent, because retries are guaranteed
Failed deliveries get retried, and a retry after a timeout means you may have already done the work. Derive a stable key for every event, such as the ticket ID plus the update timestamp, or the event ID where one is provided. Record processed keys, check before acting, expire them after a sensible window.
This is also, for what it's worth, the single most common way an integration creates duplicate tickets: a retried delivery handled twice, producing two identical tickets seconds apart with no human involved at all.
Expect events out of order
Two updates a second apart can arrive in either order, and eventually will. Before you write anything, compare the event timestamp against what you last applied for that ticket and discard anything older. Otherwise a stale event overwrites fresh data and nobody can explain the ticket that reverted itself.
Watch for deactivation
Sustained failures can leave your webhook switched off. The failure mode is horrible, because everything looks fine and simply nothing happens. Alert on a gap in received events, not just on errors, since the absence of errors is exactly what this looks like.
Sweep up afterwards
Run a job every night that queries the API for tickets updated in the last day and reconciles them against what you processed. It's cheap, it's boring, and it will one day be the reason you didn't lose four hours of events during an outage nobody noticed.
Two things that will bite you
Loops. A webhook fires, your consumer calls the Zendesk API to update the ticket, that update fires the webhook again. Exclude your own integration user in the trigger conditions, or gate on a tag your consumer sets and checks.
Payload drift. If you compose the body yourself with placeholders, someone will eventually rename a custom field and the field your consumer depends on will start arriving empty. Log payloads you could not parse, and alert on them, rather than swallowing the exception and moving on.
Frequently asked questions
How do you create a webhook in Zendesk?
In Admin Center under Apps and integrations. To create a webhook Zendesk asks for the endpoint URL, the method and the authentication, then a trigger invokes it. The Zendesk webhooks API does the same thing programmatically.
What's the difference between a Zendesk webhook and a trigger?
A trigger is the rule that decides when something happens. A webhook is the outbound HTTP call. Triggers can invoke webhooks, and webhooks can also subscribe directly to platform event types.
Does Zendesk retry failed webhooks?
Yes, failed deliveries are retried, and sustained failure can deactivate the webhook. Build for idempotency and monitor for deactivation.
How do I secure a Zendesk webhook endpoint?
Verify the signature header against the raw request body with a constant-time comparison, reject old timestamps, and serve only over HTTPS.
Should I use webhooks or poll the API?
Webhooks for reacting, plus a daily reconciliation query for anything you might have missed. Polling alone is slow and burns rate limit on nothing.
Can a webhook fire on any ticket change?
Effectively yes, by attaching it to a trigger with broad conditions, but narrow the conditions instead. Volume you filter at the source is volume your consumer never has to handle.
Real-time is how duplicates get caught
Ticket Merger reacts to tickets as they arrive rather than sweeping the queue hours later, which is why the second ticket gets merged before an agent opens it.
Start free trial14-day free trial. No credit card required.