How to create and update Zendesk triggers using the API

Managing triggers through the Zendesk UI works fine for one-off changes. But when you need to deploy the same trigger across multiple environments, sync configurations between sandbox and production, or automate trigger management at scale, the API becomes essential. This guide walks you through creating and updating Zendesk triggers programmatically, from authentication to production-ready code examples.

If you're finding yourself building increasingly complex trigger chains to handle scenarios that require understanding and judgment, you might want to explore AI-powered alternatives. Our Zendesk integration handles nuanced automation that rule-based triggers struggle with. But first, let's get you up and running with the API.

What you'll need

Before making your first API call, make sure you have these basics covered:

• Zendesk account with admin access. You'll need administrator permissions to create API tokens and manage triggers.
• API token. Generated from the Admin Center (we'll cover this in step 1).
• A tool for making HTTP requests. curl works great for testing. Postman is helpful for exploration. Any programming language with HTTP capabilities (Python, Node.js, Ruby) works for automation.
• Basic understanding of JSON. The API accepts and returns JSON payloads.

Understanding Zendesk trigger structure

Triggers in Zendesk follow a simple pattern: conditions define when a trigger runs, and actions define what happens when it does. Think of it as an "if this, then that" rule.

Here's the basic JSON structure:

{
  "trigger": {
    "title": "Notify assignee on reopen",
    "conditions": {
      "all": [
        {"field": "status", "operator": "changed", "value": "open"}
      ]
    },
    "actions": [
      {"field": "notification_user", "value": ["assignee_id", "Ticket reopened", "A customer has reopened this ticket."]}
    ]
  }
}

The conditions object contains two arrays: all (logical AND) and any (logical OR). Every condition in the all array must be true for the trigger to fire. Only one condition in the any array needs to be true.

Key fields to know:

• title: The trigger name (required)
• conditions: Defines when the trigger runs (required)
• actions: What the trigger does (required)
• active: Boolean to enable/disable (defaults to true)
• category_id: Organizes triggers into categories (optional)
• position: Controls execution order (lower numbers run first)

Important distinction: When you create a trigger with POST, you send the complete trigger object. When you update a trigger with PUT, you must include ALL conditions and actions, not just the ones you're changing. The update replaces the entire trigger configuration.

Step 1: Set up API authentication

Zendesk uses API tokens for authentication. Here's how to generate one:

1. Navigate to Admin Center > Apps and integrations > APIs > Zendesk API
2. Click the Settings tab and ensure "Token Access" is enabled
3. Click the (+) Add API token button
4. Give your token a descriptive name like "Trigger Management"
5. Copy the token immediately (it won't be shown again)

Token limits: You can have up to 256 active tokens per account. If you hit that limit, you'll need to delete an existing token before creating a new one.

Authentication format: Combine your email address with the token using /token: as the separator:

jdoe@example.com/token:6wiIBWbGkBMo1mRDMuVwkw1EPsNkeUj95PIz2akv

Test your authentication with a simple request:

curl https://your-subdomain.zendesk.com/api/v2/triggers.json \
  -u jdoe@example.com/token:YOUR_API_TOKEN

If you get a JSON response with your triggers (or an empty array if you have none), you're authenticated and ready to proceed.

Security best practices:

• Store tokens in environment variables, never in code
• Delete tokens you're not using
• Rotate tokens periodically
• Use separate tokens for different environments (dev, staging, production)

Step 2: Create your first trigger

Now let's create a trigger via API. We'll build a simple trigger that assigns tickets containing the word "urgent" to a specific group.

The endpoint is POST /api/v2/triggers.

curl https://your-subdomain.zendesk.com/api/v2/triggers.json \
  -u jdoe@example.com/token:YOUR_API_TOKEN \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{
    "trigger": {
      "title": "Route urgent tickets to Tier 2",
      "conditions": {
        "all": [
          {"field": "comment_includes_word", "operator": "includes", "value": "urgent"},
          {"field": "status", "operator": "is", "value": "new"}
        ]
      },
      "actions": [
        {"field": "group_id", "value": "20455932"},
        {"field": "priority", "value": "high"}
      ]
    }
  }'

Let's break down what's happening:

Conditions: The trigger only fires when a ticket is new (status is new) AND the comment contains the word "urgent" (comment_includes_word includes urgent). Both conditions must be true because they're in the all array.

Actions: When conditions are met, the trigger assigns the ticket to group ID 20455932 and sets priority to high.

The API response includes the created trigger with its assigned ID:

{
  "trigger": {
    "id": 360012345678,
    "title": "Route urgent tickets to Tier 2",
    "active": true,
    "conditions": {...},
    "actions": {...},
    "position": 15,
    "created_at": "2026-02-24T10:30:00Z"
  }
}

Save that ID. You'll need it for updates.

Testing your trigger: Create a test ticket with "urgent" in the description. Check that it gets assigned to the correct group and priority is set to high. If it doesn't work, check the trigger position (triggers run in order, and another trigger might be interfering).

Step 3: Update existing triggers

Updating triggers requires extra care. The PUT /api/v2/triggers/{id} endpoint replaces the ENTIRE trigger configuration. If you only send the fields you want to change, you'll lose all other conditions and actions.

Here's the safe way to update a trigger:

1. Fetch the existing trigger to get its current state
2. Modify the fields you want to change
3. Send the complete object back with PUT

curl https://your-subdomain.zendesk.com/api/v2/triggers/360012345678.json \
  -u jdoe@example.com/token:YOUR_API_TOKEN

curl https://your-subdomain.zendesk.com/api/v2/triggers/360012345678.json \
  -u jdoe@example.com/token:YOUR_API_TOKEN \
  -X PUT \
  -H "Content-Type: application/json" \
  -d '{
    "trigger": {
      "title": "Route urgent and critical tickets to Tier 2",
      "conditions": {
        "all": [
          {"field": "comment_includes_word", "operator": "includes", "value": "urgent critical"},
          {"field": "status", "operator": "is", "value": "new"}
        ]
      },
      "actions": [
        {"field": "group_id", "value": "20455932"},
        {"field": "priority", "value": "high"},
        {"field": "set_tags", "value": "urgent-routing"}
      ]
    }
  }'

Notice we added "critical" to the keywords and added a tag action. The entire conditions and actions arrays are included, not just the changes.

Handling update conflicts: If two processes try to update the same trigger simultaneously, you might get a 409 Conflict error. While triggers don't support the safe_update parameter that tickets use, you can implement your own conflict detection by checking the updated_at timestamp before making changes.

Step 4: Bulk operations

When managing triggers at scale, individual API calls become inefficient. Zendesk provides bulk endpoints for common operations.

Reordering triggers

Trigger position determines execution order. To move multiple triggers:

curl https://your-subdomain.zendesk.com/api/v2/triggers/update_many.json \
  -u jdoe@example.com/token:YOUR_API_TOKEN \
  -X PUT \
  -H "Content-Type: application/json" \
  -d '{
    "triggers": [
      {"id": 360012345678, "position": 1},
      {"id": 360012345679, "position": 2},
      {"id": 360012345680, "position": 3}
    ]
  }'

Activating and deactivating in bulk

curl https://your-subdomain.zendesk.com/api/v2/triggers/update_many.json \
  -u jdoe@example.com/token:YOUR_API_TOKEN \
  -X PUT \
  -H "Content-Type: application/json" \
  -d '{
    "triggers": [
      {"id": 360012345678, "active": false},
      {"id": 360012345679, "active": false}
    ]
  }'

Use cases for bulk operations:

• Deploying trigger configurations across environments
• Temporarily disabling triggers during maintenance
• Reordering triggers after adding new ones
• Migrating triggers between Zendesk instances

Performance considerations: Bulk updates are processed asynchronously. The API returns a job status that you can poll to check completion. For large operations (100+ triggers), consider breaking them into smaller batches.

Common patterns and examples

Here are four practical trigger patterns you can adapt for your needs.

Pattern 1: Auto-assign based on ticket type

{
  "trigger": {
    "title": "Assign incidents to L3 team",
    "conditions": {
      "all": [
        {"field": "type", "operator": "is", "value": "incident"},
        {"field": "status", "operator": "is", "value": "new"}
      ]
    },
    "actions": [
      {"field": "group_id", "value": "20456000"},
      {"field": "assignee_id", "value": "296220096"}
    ]
  }
}

Pattern 2: Escalation triggers with priority changes

{
  "trigger": {
    "title": "Escalate high-priority tickets",
    "conditions": {
      "all": [
        {"field": "priority", "operator": "is", "value": "high"},
        {"field": "status", "operator": "is", "value": "open"},
        {"field": "hours_since_open", "operator": "greater_than", "value": "4"}
      ]
    },
    "actions": [
      {"field": "priority", "value": "urgent"},
      {"field": "notification_group", "value": ["20456001", "Escalation: High priority ticket", "A high-priority ticket has been open for more than 4 hours."]}
    ]
  }
}

Pattern 3: Notification triggers with custom messages

{
  "trigger": {
    "title": "Notify manager on VIP tickets",
    "conditions": {
      "all": [
        {"field": "current_tags", "operator": "includes", "value": "vip"},
        {"field": "update_type", "value": "Create"}
      ]
    },
    "actions": [
      {"field": "notification_user", "value": ["296220100", "New VIP ticket: {{ticket.title}}", "A VIP customer has submitted a new ticket.\n\nTicket ID: {{ticket.id}}\nRequester: {{ticket.requester.name}}\nPriority: {{ticket.priority}}"]}
    ]
  }
}

Pattern 4: Webhook triggers for external integrations

{
  "trigger": {
    "title": "Send ticket to CRM",
    "conditions": {
      "all": [
        {"field": "status", "operator": "changed", "value": "solved"}
      ]
    },
    "actions": [
      {"field": "notification_webhook", "value": ["01G8Z5K1234567890ABCDEF", "{\"ticket_id\": \"{{ticket.id}}\", \"status\": \"{{ticket.status}}\", \"solved_at\": \"{{ticket.solved_at}}\"}"]}
    ]
  }
}

Error handling and troubleshooting

When working with the Triggers API, you'll encounter these HTTP status codes:

Common issues and fixes:

Invalid JSON errors: The API is strict about JSON formatting. Common mistakes include trailing commas, unquoted keys, and improper escaping of special characters in strings.

Validation errors (422): These usually mean a condition or action field doesn't exist or has an invalid value. Double-check field names against the conditions reference and actions reference.

Trigger not firing after creation: Remember that triggers execute in position order. If another trigger modifies the ticket first, your new trigger's conditions might no longer match. Try moving your trigger to an earlier position.

Rate limiting: Zendesk allows 700 requests per minute for most endpoints. If you hit the limit, back off and retry with exponential delay.

Best practices for API trigger management

After working with the Triggers API across multiple projects, here are practices that save time and prevent headaches:

Version control your trigger configurations. Store trigger JSON in Git. This enables code review for trigger changes, easy rollbacks when something breaks, and documentation of why specific conditions exist.

Test in sandbox first. Always validate trigger logic in a sandbox environment before deploying to production. Trigger interactions can be complex, and what works in isolation might conflict with existing triggers.

Use consistent naming conventions. Prefix triggers by function ("ROUTE-", "NOTIFY-", "ESCALATE-") to make them scannable in the UI. Include ticket references in commit messages when triggers are tied to specific issues.

Document trigger dependencies. When triggers interact (one trigger sets a tag that another checks), document these relationships. A change to one trigger can break others in subtle ways.

Monitor trigger performance. Use the usage sideloads (?include=usage_24h) to track how often triggers fire. Triggers that never fire might have incorrect conditions. Triggers that fire constantly might be causing unnecessary load.

Know when to use the UI vs API. Use the UI for one-off changes and experimentation. Use the API for deployments across environments, bulk updates, and anything you want to version control.

When to consider eesel AI for automation

Triggers work well for straightforward, rule-based automation. But they have limits. They can't understand context, sentiment, or intent. They require exact matches on keywords rather than understanding what a customer actually needs.

At eesel AI, we approach automation differently. Instead of building rigid trigger logic, you hire an AI teammate that learns your business and makes intelligent decisions.

Here's when you might want to consider our Zendesk integration alongside or instead of complex triggers:

Complex automation requiring understanding. Want to escalate tickets based on sentiment, urgency, or customer intent? Our AI reads and understands ticket content, not just field values.

Natural language conditions. Instead of "if tag equals X," you can say things like "if the customer seems frustrated about billing." The AI understands context and nuance.

Automatic ticket resolution. While triggers can notify and tag, our AI Agent can actually resolve tickets autonomously. It learns from your past tickets and help center to provide accurate responses without manual setup.

Progressive automation. Start with AI drafting replies for agent review. As it proves itself, let it send responses directly. Eventually, it can handle full frontline support. You're in control of the pace.

If you're finding yourself building increasingly complex trigger chains, it might be time to explore a different approach. See how eesel AI works with Zendesk.