How to set up a Zendesk webhook for ticket created events

Webhooks are one of the most powerful tools in Zendesk's automation arsenal. They let you send real-time notifications to external systems whenever something happens in your help desk. When a customer submits a new ticket, a webhook can instantly alert your team in Slack, update your CRM, or trigger custom workflows in your own applications.

Setting up a Zendesk webhook for ticket created events isn't complicated, but there are some important decisions to make along the way. This guide walks you through the entire process, from initial configuration to testing and troubleshooting.

What you'll need

Before you start, make sure you have:

• A Zendesk Support account on Team plan or higher (webhooks aren't available on the Essential plan)
• Admin access or a custom role with webhook creation permissions
• An endpoint URL that can receive HTTP POST requests (this could be a service like Zapier, a custom API, or a webhook testing site)
• An API token if you plan to use authentication (recommended for production)

Trial accounts have some limitations: maximum of 10 webhooks and 60 invocations per minute. That's plenty for testing, but you'll want to upgrade before going live with heavy automation.

Step 1: Create the webhook in Zendesk

First, you need to create the webhook itself. This defines where Zendesk will send data and how it will authenticate.

Navigate to Admin Center → Apps and integrations → Webhooks. Click Actions in the top right, then select Create webhook.

You'll see a form with several fields to configure:

Name and description: Give your webhook a clear name like "New Ticket Notification" so you can identify it later. The description is optional but helpful if you have multiple webhooks.

Endpoint URL: This is where Zendesk will send the webhook data. It must be a valid HTTPS URL that can accept POST requests. For testing, you can use a service like webhook.site to see the payloads without building your own endpoint.

HTTP method: For event subscriptions, this must be POST. If you're connecting to triggers instead, you can choose GET, POST, PUT, PATCH, or DELETE depending on what your endpoint expects.

Request format: For event subscriptions, this must be JSON. Trigger-connected webhooks also support XML and form-encoded formats.

Authentication: This is strongly recommended for production. Zendesk supports three methods:

• API key: Adds a custom header with your key
• Basic auth: Username and password, base64-encoded
• Bearer token: OAuth 2.0-style token in the Authorization header

Once you've filled everything out, click Create at the bottom. Your webhook is now created but not yet connected to any events. That's the next step.

Step 2: Choose your connection method

Here's where you need to make an important decision. Zendesk offers two ways to connect webhooks to ticket activity, and you can't change this later without deleting and recreating the webhook.

Option A: Event subscription (zen:event-type:ticket.created)

This approach subscribes your webhook directly to Zendesk's event stream. When any ticket is created, your webhook fires.

Pros:

• Fires for every ticket created, guaranteed
• Simple setup: no triggers needed
• Near real-time delivery

Cons:

• Fixed payload structure (you can't customize what data gets sent)
• No filtering: you get every ticket, even spam
• Must use POST and JSON

Option B: Trigger-connected webhook

This approach connects your webhook to a Zendesk trigger. The trigger decides when to fire based on conditions you define.

Pros:

• Full control over when the webhook fires (specific groups, priorities, tags)
• Customizable payload using Zendesk placeholders
• Can filter out noise (spam, test tickets, etc.)

Cons:

• Requires creating and maintaining a trigger
• Slightly more complex setup

Which should you choose? If you need every ticket and don't mind filtering on your end, use event subscriptions. If you only want specific tickets (like high-priority issues or tickets from certain organizations), use trigger-connected webhooks.

Step 3: Configure the trigger (for trigger-connected webhooks)

If you chose Option B, you now need to create a trigger that invokes your webhook.

Navigate to Admin Center → Objects and rules → Triggers. Click Add trigger.

Set your conditions:

At minimum, add: Ticket | Is | Created

You can add more conditions to filter which tickets trigger the webhook:

• Priority is High or Urgent
• Group is "Technical Support"
• Tags contain "escalated"
• Organization is a specific VIP customer

Add the webhook action:

Under Actions, select Notify active webhook from the dropdown. Choose the webhook you created in Step 1.

Configure the JSON payload:

This is where you define what data gets sent to your endpoint. Use Zendesk placeholders to insert ticket data:

{
  "ticket_id": "{{ticket.id}}",
  "subject": "{{ticket.title}}",
  "description": "{{ticket.description}}",
  "requester_email": "{{ticket.requester.email}}",
  "requester_name": "{{ticket.requester.name}}",
  "priority": "{{ticket.priority}}",
  "status": "{{ticket.status}}",
  "group": "{{ticket.group.name}}",
  "assignee": "{{ticket.assignee.name}}",
  "created_at": "{{ticket.created_at}}",
  "tags": "{{ticket.tags}}",
  "url": "{{ticket.link}}"
}

Zendesk will replace each placeholder with the actual ticket data when the webhook fires. You can also use Liquid markup for conditional logic.

Important: Add a nullifying condition to prevent infinite loops. Since the trigger fires when a ticket is created, and the webhook might update the ticket, you need a condition that stops the trigger from firing again. A common pattern is to add a tag in your webhook response and exclude tickets with that tag.

Step 4: Test your webhook

Before relying on your webhook in production, you need to verify it works.

Test via the webhook settings:

Go back to Admin Center → Apps and integrations → Webhooks. Find your webhook and click the three-dot menu, then Test webhook.

Zendesk will send a test payload to your endpoint. The test uses a static signing secret (dGhpc19zZWNyZXRfaXNfZm9yX3Rlc3Rpbmdfb25seQ==) so you can verify signature validation.

Test with a real ticket:

Create a test ticket in Zendesk. Check your endpoint to verify:

• The request arrived
• The payload contains expected data
• Authentication headers are present (if configured)
• The signature validates (if using HMAC)

Check webhook activity logs:

Zendesk keeps logs of webhook invocations for 7 days. You can access these via the Webhooks API to see delivery status, response codes, and any errors.

Understanding the webhook payload

When Zendesk sends a webhook for a ticket created event, the payload structure differs based on your connection method.

Event-subscribed payload

For direct event subscriptions, the payload follows a fixed schema:

{
  "type": "zen:event-type:ticket.created",
  "account_id": 22129848,
  "id": "cbe4028c-7239-495d-b020-f22348516046",
  "time": "2025-01-08T10:12:07.672Z",
  "zendesk_event_version": "2022-11-06",
  "subject": "zen:ticket:5158",
  "detail": {
    "actor_id": "8447388090494",
    "assignee_id": "8447388090494",
    "brand_id": "8447346621310",
    "created_at": "2025-01-08T10:12:07Z",
    "description": "I need help with my order",
    "id": "5158",
    "is_public": true,
    "organization_id": "8447346622462",
    "priority": "LOW",
    "requester_id": "8447388090494",
    "status": "OPEN",
    "subject": "Order help needed",
    "tags": ["order", "help"],
    "via": { "channel": "web_service" }
  },
  "event": { "meta": { "sequence": { "id": 12345, "position": 1 } } }
}

Key fields include the ticket ID, subject, description, requester ID, priority, status, and creation timestamp.

Trigger-connected payload

For trigger-connected webhooks, the payload is whatever you defined in the trigger action. You have full control over the structure and content.

Authentication and security

Webhooks can carry sensitive ticket data, so securing them is important.

Authentication methods:

• API key: Add a header like X-API-Key: your-secret-key
• Basic auth: Base64-encoded username:password in the Authorization header
• Bearer token: OAuth 2.0 style Authorization: Bearer your-token

HMAC signature verification:

Zendesk supports HMAC-SHA256 signatures to verify webhook authenticity. Each webhook gets a unique signing secret. Zendesk signs every request by computing an HMAC over the timestamp and request body.

Your endpoint should:

1. Extract the signature from x-zendesk-webhook-signature header
2. Extract the timestamp from x-zendesk-webhook-signature-timestamp header
3. Compute the expected signature using your signing secret
4. Compare using constant-time comparison to prevent timing attacks

Best practices:

• Always use HTTPS endpoints
• Verify signatures in production
• Store signing secrets securely (not in code repositories)
• Implement idempotency to handle duplicate deliveries
• Return 200 status quickly; process asynchronously if needed

Troubleshooting common issues

Even with careful setup, webhooks sometimes don't work as expected. Here are the most common issues and how to fix them.

Webhook not firing:

• Check trigger conditions: are they actually being met?
• Verify the trigger is active (not disabled)
• Look for nullifying conditions that might prevent execution
• Confirm the webhook status is "active"

Endpoint errors (4xx, 5xx responses):

• 410 Gone: Your endpoint returned an error; check your server logs
• 429 Too Many Requests: You're being rate limited; implement backoff
• 5xx errors: Server-side issues on your end

Timeout issues:

Zendesk has a strict 10-second timeout. If your endpoint doesn't respond within 10 seconds, Zendesk marks it as failed and retries. Make sure your endpoint responds quickly, processing heavy work asynchronously if needed.

Circuit breaker triggered:

If your webhook fails at a 70% error rate or accumulates 1,000+ errors in 5 minutes, Zendesk disables it automatically. You'll need to fix the underlying issue and re-enable the webhook manually.

Missing activity logs:

Zendesk only keeps webhook activity logs for 7 days. If you need longer retention, you'll need to log webhook events on your own infrastructure.

Alternative: Automating without webhooks

Webhooks are powerful, but they're not always the right tool. They require technical setup, ongoing maintenance, and error handling. If you want automation without the complexity, there are alternatives.

We built eesel AI to handle support automation without requiring webhooks or custom development. Instead of configuring endpoints and parsing JSON payloads, you simply connect eesel AI to your Zendesk account. It learns from your past tickets and help center articles, then handles routine tasks automatically.

Here's the difference:

With eesel AI, you can:

• Auto-tag and route tickets based on content
• Draft responses for your agents
• Handle common questions end-to-end
• Escalate complex issues to humans

The best part? You can test it on past tickets before going live. No risk of breaking production workflows while you fine-tune the setup.

Start automating your Zendesk workflows today

Setting up a Zendesk webhook for ticket created events gives you real-time visibility into new support requests. Whether you're notifying Slack channels, syncing to a CRM, or triggering custom workflows, webhooks provide the glue between Zendesk and the rest of your stack.

The process is straightforward: create the webhook, choose your connection method, configure a trigger (if needed), and test thoroughly. Pay attention to authentication and error handling to ensure reliable operation.

If webhooks feel like overkill for your needs, consider whether an AI-powered approach might work better. Tools like eesel AI can automate ticket handling without any webhook configuration or endpoint management. You can try eesel AI free and see how it handles your specific ticket types before committing to a webhook-based solution.

Either way, the goal is the same: spend less time on manual ticket management and more time actually helping customers.