Creating a webhook and attaching it to a trigger

Defining a webhook and calling it from a trigger. Two pieces, and the conditions on the trigger are the part to be careful with.

Defining a webhook and calling it from a trigger. Two pieces, and the conditions on the trigger are the part to be careful with.

Create the webhook

1. Open Admin Center, then Apps and integrations > Webhooks > Webhooks.
2. Click Create webhook and choose how it will be called: Zendesk events, or Trigger or Automation. This is the first question and it is not editable later in the way you would hope, so read it properly.
3. Give it a Name and Description, naming what it tells and to whom.
4. Set the Endpoint URL, the Request method and the Request format: JSON, XML or form-encoded.
5. Set the Authentication the other system expects: none, an API key, basic authentication or a bearer token. Add header covers anything else it wants.
6. Test webhook, then Create webhook.

A webhook set to Trigger or Automation is not connected to anything yet. You do that from the trigger, afterwards, which is the next section.

Call it from a trigger

1. Create or edit a trigger.
2. Set conditions narrowly. See below.
3. Add the action that notifies the webhook.
4. Build the message body, using placeholders for the ticket data.
5. Test on one ticket before activating it.

Narrow the conditions

A webhook creates work in a system you do not control. Conditions that are slightly too wide mean hundreds of unwanted records over there, and cleaning that up is somebody else's afternoon.

Start with a test tag as a condition, prove it works, then widen deliberately.

Two numbers worth having in mind while you build the body. The payload cannot exceed 16,000 characters, so a message carrying a long comment can be rejected by a ticket you did not test with. And a failed call is retried automatically up to three times, which means the other system can receive the same event more than once and should be able to cope with that.

The message body

Send what the other system needs and nothing more. A body containing the whole ticket including all comments sends customer conversations to another system, which is a data question as much as a technical one.

Authentication

Whatever the other system requires, configured on the webhook rather than in the trigger. That keeps credentials in one place and out of your business rules.

A webhook that calls back into your own Zendesk is a special case

Some webhooks point at your own account rather than at another system, to update a ticket the trigger cannot reach. Those were usually authenticated with an API token, and that route is closing: no new tokens can be created from 27 October 2026 and every existing one stops working on 30 April 2027.

For most of these, Action Builder does the same job without any credential at all, and is the simpler move. Zendesk has said it will add OAuth support for webhooks before the April deadline, but no date has been given, so do not plan around it. If yours has to keep calling back with a token, tell us and we will look at it with you well before the date rather than on it.

See also

• Testing a webhook and finding faults
• Actions in a trigger
• Testing a trigger without bothering customers