How Do You Automatically Put the Zendesk Ticket ID in a Custom Field?

To put a Zendesk ticket ID into a custom field automatically, create a webhook that sends a PUT request to https://YOUR_SUBDOMAIN.zendesk.com/api/v2/tickets/{{ticket.id}}.json, then fire it from a trigger on ticket creation with a JSON body that writes "{{ticket.id}}" into the field. Standard trigger actions can't copy the ID on their own, so the ticket has to update itself through the API. Before you build it, know that Zendesk's own help center says this trigger-plus-webhook pattern "isn't recommended or supported", because the API update can land partway through a trigger cycle, and it points to Action Builder or ZIS flows instead.

Why would you copy the ticket ID into a custom field?

Zendesk generates a unique ID for every ticket, but that ID is a system property, not something a regular trigger action can write into a custom field. Teams want it in a field when they need to:

• Store formatted references (like "CHG00123" for change tickets)
• Send ticket IDs to external systems that read them from a specific field
• Build reporting that relies on the ID sitting in a particular field
• Meet internal tracking or compliance requirements

As one Zendesk user put it: "I have a business case related to some external reporting tools that requires this field."

How does the webhook workaround work?

Three pieces work together:

1. A webhook that calls the Zendesk Tickets API
2. A trigger that fires when a ticket is created
3. Placeholders that insert the ticket ID into the request

When a ticket meets the trigger conditions, the trigger queues the webhook, and the webhook updates that same ticket's custom field with its own ID. Zendesk is, in effect, calling itself to make an update triggers can't make directly.

How do you set it up, step by step?

Step 1: Create your custom field

1. In Admin Center, go to Objects and rules > Tickets > Fields
2. Click Add field
3. Select Text as the field type
4. Enter a display name (for example, "Ticket Reference")
5. Set visibility for agents and end users as you need
6. Save the field and note its field ID; you'll need it in Step 3

Step 2: Create the webhook

1. Go to Admin Center > Apps and integrations > Webhooks
2. Click Create webhook
3. Choose Trigger or automation as the connection method (a webhook subscribed to Zendesk events can't be connected to a trigger)
4. Name it, for example "Update Ticket Field"
5. For the Endpoint URL, enter https://YOUR_SUBDOMAIN.zendesk.com/api/v2/tickets/{{ticket.id}}.json

The {{ticket.id}} placeholder in the URL is replaced with the real ticket number each time the webhook fires.

6. Select PUT as the request method
7. Select JSON as the request format
8. For authentication, choose Basic authentication: the username is [email protected]/token and the password is an API token (Zendesk also offers API key and Bearer token options)
9. Click Create webhook

Zendesk lets you test the webhook against a ticket ID. The test sends a real request, so a PUT test will change the ticket you name; use a throwaway test ticket.

Step 3: Configure the trigger

1. Go to Admin Center > Objects and rules > Business rules > Triggers
2. Click Add trigger
3. Name it, for example "Populate Ticket ID on Creation"
4. Set the conditions:
   • Ticket: Is > Created
   • Add further conditions if only some ticket types need the ID
5. Under Actions, select Notify active webhook
6. Choose the webhook from Step 2
7. In the JSON body field, paste:

json

{
 "ticket": {
   "custom_fields": [{
     "id": YOUR_CUSTOM_FIELD_ID,
     "value": "{{ticket.id}}"
   }]
 }
}

Replace YOUR_CUSTOM_FIELD_ID with the field ID from Step 1. When the trigger fires, {{ticket.id}} becomes the actual ticket number.

8. Click Create

Timing: a trigger queues the webhook job rather than running it inline, so the field fills a few seconds after the ticket is created, not in the same update.

How do you add a prefix to the ticket ID?

Put the prefix in the JSON value, in front of the placeholder:

json

{
 "ticket": {
   "custom_fields": [{
     "id": YOUR_CUSTOM_FIELD_ID,
     "value": "CHG00{{ticket.id}}"
   }]
 }
}

That turns ticket #12345 into "CHG0012345" in the custom field, which suits change-ticket references and other formatted identifiers. Any content placeholder can go in the body the same way, so you can include the subject, requester details or assignee as well.

How do you check that it worked?

1. Create a test ticket that meets the trigger conditions
2. Wait a few seconds for the webhook job to run
3. Open the ticket and check the custom field
4. The ticket ID should be there

If it's empty, check:

• The custom field ID in the JSON body
• The webhook's authentication (the /token suffix on the email is the usual miss)
• That the trigger conditions are actually met
• The subdomain in the endpoint URL
• The webhook's activity log in Admin Center for error responses

Can the same webhook copy other ticket data?

Copying other ticket data to custom fields

Yes. The same webhook can copy almost any ticket data into custom text fields without separate API development. Swap in placeholders like {{ticket.title}} or {{ticket.description}}, or copy one custom field into another with {{ticket.ticket_field_FIELD_ID}}.

Updating multiple fields at once

Add more objects to the custom_fields array:

json

{
 "ticket": {
   "custom_fields": [
     {"id": 123456, "value": "{{ticket.id}}"},
     {"id": 789012, "value": "{{ticket.status}}"},
     {"id": 345678, "value": "{{ticket.priority}}"}
   ]
 }
}

Working with dropdown and multi-select fields

For dropdown fields, the value must match the tag of the option you want. For multi-select fields, send an array of option tags. Match the format to the field type or the update is rejected.

What are the risks and limits of this approach?

Zendesk doesn't support it. Zendesk's article on using a trigger and a webhook to update tickets says errors are likely when business rules and the API update a ticket at the same time. The API update lands at an unpredictable point in the trigger cycle, so other triggers may fire when they shouldn't, or not fire at all. Zendesk recommends Action Builder or Zendesk Integration Services (ZIS) flows for this kind of self-update. If you use the webhook anyway, keep the trigger narrow and test it next to your other creation triggers.

Timeouts and retries: per Zendesk's developer docs, webhook requests time out after 12 seconds, and timed-out requests are retried up to five times. A call back to Zendesk itself normally returns well inside that window. If a webhook's error rate passes 70% in five minutes, a circuit breaker pauses it.

Rate limits: the webhook's API calls count toward your account's API rate limit. That rarely matters for one call per new ticket, but it adds up at high volume. Trial accounts are capped at 10 webhooks and 60 invocations per minute.

Closed tickets: closed tickets are read-only, so the update only works on tickets that aren't closed. Old closed tickets keep an empty field.

Frequently asked questions

Can a standard Zendesk trigger copy the ticket ID into a field?

No. Trigger actions can set a field to a fixed value but can't insert the ticket's own ID, which is why the webhook calls the Tickets API instead.

Is the trigger-and-webhook method officially supported by Zendesk?

No. Zendesk says the workflow isn't recommended or supported because of race conditions with other business rules, and points to Action Builder or ZIS flows. Many admins use the webhook method anyway; test it in a sandbox first.

How long after ticket creation does the field fill in?

Usually a few seconds. The trigger queues the webhook job, and the field is written when that job's API call completes.

Additional resources:

• Zendesk: Creating webhooks to interact with third-party systems
• Zendesk: Using placeholders
• Zendesk Developer Docs: Creating and updating tickets