As most of you know, I'm a big fan of using webhooks in Zendesk. Well, fan might be a bit too excessive a definition, but once you know how to use them you can automate a lot of cool things with the platform that aren't possible with regular triggers and automations.

Webhooks, for those that don't know, allow you to call external platforms and urls from within the Zendesk platform. They're useful for sending out notifications to e.g. Slack, alert your CRM of a new customer is created, update your data warehouse once a ticket is resolved, or for calling Zendesk's own API to update ticket data that's not easily updatable via triggers.

Webhooks

Over the years I've written a series of articles that get you started with Zendesk webhooks:

Your new Zendesk super power: Internal Webhooks

Zendesk offers robust triggers and automations to modify tickets. For complex tasks like copying field data, Zendesk’s Webhooks can execute API calls for advanced modifications. This article explains how to utilize these tools.

Internal NoteThomas Verschoren

Update a requester name via webhooks and custom fields

Update a requesters’ profile based on form field input.

Internal NoteThomas Verschoren

Automatically deflect Zendesk spam tickets via triggers and webhooks

From time to time spammers use open API endpoint in Zendesk to flood your inbox with tickets. This article shows an efficient and automatic way to deflect these tickets.

Internal NoteThomas Verschoren

All of the examples I've listed about are webhooks that are invoked via triggers and automations. They react to tickets being created and updated – with optional conditions being added – and invoke a webhook with a custom payload.

Reacting to updates to other object types

Triggers for ticket updates is not the only scenario where webhooks can come in use. There's also custom objects (Service Contract is expiring, better alert the customer for an upcoming renewal), users (new user created, let's add him to our CRM) or organizations (and alert the account manager), or updates to help center articles that might warrant a connection to an external platform.

Last year Zendesk added a series of new events that could fire webhooks to Admin Center, allowing you to react to updates to users, agents, organizations, omnichannel routing and plenty of other events on the platform.

These give Zendesk Admins an easy way to integrate the platform into the wider ecosystem of software used in their company, with limited development effort.

If you want some inspiration on what's possible, take a look at the articles below:

Webhooks for User and Organisation events

Zendesk recently launched an expansion on their webhooks functionality that allows you to subscribe to changes in Users and Organizations and act upon those actions. In this article we’ll show how you can auto-complete agent profiles with a signature, alias and profile image upon creation.

Internal NoteThomas Verschoren

Publish new Articles to Slack via the new Webhooks for Zendesk Help Center

Learn how to publish Zendesk Guide articles to Slack by using the new Zendesk Events for Guide webhooks.

Internal NoteThomas Verschoren

One important difference between trigger based webhooks and these native Zendesk events is that there's no conditions like you have with triggers . If you fire a webhook upon user creation, it'll fire for every user created, and it's the receiving webhook that can, or should, filter the incoming requests.

{
  "type": "zen:event-type:user.created",
  "account_id": 123456789,
  "id": "abb40a1b-f6d0-4d56-9602-99918f379ecb,
  "subject": "zen:user:0987654321",
  "time": "2025-04-08T16:47:23Z",
  "zendesk_event_version": "2022-06-20",
  "detail": {
    "created_at": "2025-04-08T16:47:20Z",
    "email": "bruce.wayne@gothamcity.com",
    "external_id": "THX-1138",
    "default_group_id": "0",
    "id": "11223344556677",
    "organization_id": "0",
    "role": "end-user",
    "updated_at": "2025-04-08T16:47:20Z"
  }
}

Ticket Events

As discussed above, firing off webhooks via triggers is quite useful in many scenarios ranging from updating internal Zendesk objects, to notifying external platforms.

When creating webhook integrations for customers I do find myself often creating just stub triggers. Dump triggers that fire upon every ticket creation/update/change without any complex conditions or filters. Especially in scenarios where you want to use those webhooks as some kind of event firehose that connects to a bigger data repository, or for logging purposes, or in scenarios where you want to look at the possibility of enriching ticket data for any update.

In those scenarios you end up with potentially dozens of small triggers that clutter up your trigger list. Luckily with a recent update to webhooks this "issue" is not resolved.

You can now fire off webhooks for any ticket event directly from the webhook interface, without the need of creating an additional trigger. It's a small quality of life update, but makes it easier to manage triggers and webhooks alike.

Webhooks can fire for the following ticket events:

And, just like with the other Zendesk events, you get any event that matches your chosen event types, and it's the receiving webhook that can and should filter the incoming payloads.

{
  "account_id": 22129848,
  "detail": {
    "actor_id": "8447388090494",
    "assignee_id": "8447388090494",
    "brand_id": "8447346621310",
    "created_at": "2025-01-08T10:12:07Z",
    "custom_status": "8447320465790",
    "description": "ticket_info_desc_2294a6e9ece2",
    "external_id": null,
    "form_id": "8646151517822",
    "group_id": "8447320466430",
    "id": "5158",
    "is_public": true,
    "organization_id": "8447346622462",
    "priority": "LOW",
    "requester_id": "8447388090494",
    "status": "OPEN",
    "subject": "ticketinfo_2294a6e9ece2",
    "submitter_id": "8447388090494",
    "tags": [
      "ticket-info-test-tag"
    ],
    "type": "TASK",
    "updated_at": "2025-01-08T10:12:07Z",
    "via": {
      "channel": "web_service"
    }
  },
  "event": {},
  "id": "cbe4028c-7239-495d-b020-f22348516046",
  "subject": "zen:ticket:5158",
  "time": "2025-01-08T10:12:07.672717030Z",
  "type": "zen:event-type:ticket.created",
  "zendesk_event_version": "2022-11-06"
}

I've already updated my Spam filtering workflow. A new webhook now notifies my Cloudflare Worker on zen:event-type:ticket.marked_as_spam events for any ticket I manually map as spam. The worker then runs some regex on the ticket contents, and adds unique elements like the subject to the list it uses for future spam filtering. Makes the whole flow self-improving and, hopefully, even more efficient.

Messaging Events

Alongside the new Ticket events, there's also a short list of new Messaging events added. Honestly, can't think of any uses for these events yet, but if you have some ideas, please add them to the comments below!

Conclusion

These updates might seem like small convenience updates for workflows that can already be accomplished via traditional triggers, but it does feel like another piece in a bigger puzzle.

Traditionally triggers and automations were the core of any Zendesk workflow. Any (re)action to a ticket update was handled via triggers, and they were the only way to actively update these tickets.
But over the last few months it seems Zendesk is moving a lot of the responsibilities that used to be owned by triggers away from them.

Example 1: Assignment.

Where ticket routing and assignment was usually done by triggers, we now see them being shifted towards Omnichannel routing and Queues.

Beyond triggers. Moving to queue only assignment in Zendesk

What happens if we trust queues for assignment and remove any assignment triggers from a Zendesk instance?

Internal NoteThomas Verschoren

Example 2: Copilot Procedures

We used to use a combination of macros and triggers to update tickets based on certain conditions. But with the arrival of Agent Copilot a lot of the actions done on a ticket like automated comments, escalation to external APIs, updating ticket fields e.a. are now all done based on procedures and actions.

We can even invoke the Zendesk API via Copilot Actions, so things where we used to use internal webhooks and triggers, can now become procedures and actions.

Zendesk Agent Copilot hackathon together with Next Matter

What happens if you combine Zendesk Agent Copilot, a partner like Next Matter and Internal Note? This article tells the story of our hackathon last December.

Internal NoteThomas Verschoren

Example 3: Action Builder

The final nail in the coffin for triggers might be the arrival of Action Builder. This new announcement from Zendesk Relate 2025 offers a visual workflow builder that can react to ticket updates and execute actions on both tickets and external platforms. If you think: hey, that sounds like a visual trigger builder.. you and I should become friends and have a coffee!

So what's left for triggers once Zendesk Admins (and Zendesk itself) shifts those responsibilities away from them? Notifying customers over email is one. Calling native functions like CSAT, side conversations or lookup fields is two. Can't really think of a three.

To be honest, I kinda like this. Anyone who manages big complex environments in Zendesk knows the issues that come with triggers. We've all followed the breadcrumbs of interlinked and overly complex trigger setups with complex IF NOT and ELSE conditions. Moving these towards the new action builder with its nested conditions seems so much better.

Similarly, combining webhooks and events in one logical element will also make management of these easier to grasps. And if I can have one feature request? I'd love just a few filters on these native Zendesk events. Just to reduce unwanted traffic across the network.