How to Connect Zendesk to OpenClaw: Setup, Models, and Workflow Guide

If you're searching for "how to connect Zendesk to OpenClaw", the real question is usually not just whether the connection is possible. It's how to make Zendesk usable inside an OpenClaw workflow with the right model, the right context, and the right level of control.

That's the practical framing.

OpenClaw gives you the orchestration layer: connectors, skills, tools, prompts, approvals, and the ability to run workflows where your team already works. Zendesk provides the domain context. The integration becomes valuable when those two pieces are connected cleanly.

Zendesk + OpenClaw: What's Actually Happening Here

When someone searches for "how to connect Zendesk to OpenClaw," they're really asking one of two things. Either they're running OpenClaw on their own infrastructure and need a reliable integration path for their support queue, or they use Cody (managed OpenClaw hosting) and want to understand what's happening behind the scenes.

Zendesk is the system of record for millions of support teams — tickets, users, organizations, macros, SLAs, views, and the help center. Connecting it to OpenClaw means your AI agent can triage incoming tickets, draft replies in your brand voice, surface SLA risks, and escalate to the right team — all from Slack without opening the Zendesk agent workspace.

The landscape shifted dramatically in mid-2026. At Relate 2026 (May 19), Zendesk announced a two-directional MCP strategy: the MCP Client (early access, June 10) lets Zendesk AI Agents connect out to external MCP tools, while the MCP Server (early access, coming summer 2026) will let external AI systems connect in to Zendesk tickets, knowledge, and data. It's the biggest integration unlock Zendesk has shipped in years.

Path A: Zendesk's Official MCP Server — Coming Summer 2026 (Recommended When Available)

Zendesk's MCP Server is currently in development with early access expected summer 2026. When it launches, it will be the cleanest path: businesses connect Zendesk tickets, knowledge articles, and other data to external AI systems in a governed way — no custom proxy required.

Based on Zendesk's architecture and the MCP Client implementation (which is already in early access), here's what to expect:

What the MCP Server will likely expose:

• Ticket CRUD — read, create, update, and comment on tickets
• User and organization lookups — pull requester context before every reply
• Knowledge base search — find matching help center articles
• View queries — pull ticket lists from saved views
• SLA and metric data — surface breach risks

How this will connect to OpenClaw: When the MCP Server is generally available, use the endpoint and authentication instructions in Zendesk's official documentation. Do not configure a guessed server URL. After adding the documented server, verify it with openclaw mcp doctor zendesk --probe.

⚠️ Important timing note: The MCP Server is expected in "early access summer 2026," which means mid-to-late summer at best, and potentially longer if Zendesk prioritizes the MCP Client rollout first. For production use in July 2026, you need Path B or C below.

Path B: Zendesk REST API Proxy + OpenClaw Skill File (Best for Today)

Until the official MCP Server ships, the most reliable path is a thin HTTP proxy that wraps Zendesk's battle-tested REST API. Zendesk's API is one of the most mature in the support space — well-documented, predictable, and with solid pagination patterns.

Step 1: Generate a Zendesk API Token

Go to Zendesk Admin → Apps & Integrations → APIs → Zendesk API. Enable token access and generate a new token.

Authentication uses HTTP Basic:

• Username: {agent_email}/token
• Password: {api_token}

If you're using OAuth instead, Zendesk supports the Authorization Code grant flow. Create an OAuth client under Admin → Apps & Integrations → APIs → OAuth Clients. But for OpenClaw proxy use, API tokens are simpler and sufficient.

Step 2: Understand Zendesk's API Surface

Zendesk's API is organized into clear namespaces:

The search endpoint is the powerhouse. It supports Zendesk's query syntax:

GET /api/v2/search.json?query=type:ticket status:open priority:urgent
GET /api/v2/search.json?query=type:ticket assignee:jane@company.com status<pending
GET /api/v2/search.json?query=type:ticket tags:bug created>2026-07-01

Combined with sort parameters (sort_by=created_at, sort_order=desc), this lets you build virtually any queue query.

Step 3: Build the Proxy Service

Your proxy accepts simple HTTP requests from OpenClaw and translates them into Zendesk API calls:

• GET /zendesk/tickets?status=open&priority=urgent → returns ticket queue filtered by status/priority
• GET /zendesk/ticket/12345 → returns full ticket with comments, requester info, SLA metrics
• GET /zendesk/search?q=printer → searches tickets, articles, and users for "printer"
• POST /zendesk/ticket/12345/reply → posts an internal note or public reply
• GET /zendesk/metrics → returns SLA breach summary across all open tickets

The proxy handles authentication (API token → HTTP Basic), pagination (cursor-based for search, offset-based for list endpoints), comment threading, and response formatting.

Step 4: Write the Skill File

Create ~/.openclaw/skills/zendesk.md documenting your team's SLA targets, priority conventions, and common search patterns:

# Zendesk Skill

## SLA Targets
- Urgent: First reply within 15 min, Resolution within 1 hour
- High: First reply within 1 hour, Resolution within 4 hours
- Normal: First reply within 8 hours, Resolution within 24 hours
- Low: First reply within 24 hours, Resolution within 72 hours

## Priority Conventions
- Urgent: Production outage, security incident, executive escalation
- High: Blocking issue, SLA breach risk
- Normal: Standard support request
- Low: Feature request, documentation feedback

## Common Queries
- **Queue review:** GET /zendesk/tickets?status=open&sort=priority
- **SLA risk:** GET /zendesk/metrics — returns tickets approaching breach
- **Customer context:** GET /zendesk/user?email={email} → GET /zendesk/tickets?requester={user_id}
- **Ticket detail:** GET /zendesk/ticket/{id}
- **Search across org:** GET /zendesk/search?q="product X"&type=ticket

## Important
- SLA data lives in ticket_metrics, not the ticket object — always fetch metrics separately
- Rate limit: 700 requests/min for most plans
- Search pagination uses cursor tokens, not offsets
- Custom ticket fields need explicit property names in API requests

Path C: Community MCP Servers + Composio Zendesk Toolkit

The community moved fast while Zendesk built its official MCP server. Several mature Zendesk MCP toolkits exist:

For OpenClaw, the Composio toolkit is the most battle-tested option. Configure it in your OpenClaw Gateway:

{
  mcp: {
    servers: {
    "zendesk-composio": {
      url: "https://mcp.composio.dev/zendesk",
      transport: "streamable-http",
      headers: {
        "X-Composio-API-Key": { source: "env", provider: "default", id: "COMPOSIO_API_KEY" }
      }
    }
    }
  }
}

When to use a community server instead of the API proxy:

• You want a pre-built MCP tool surface without writing HTTP proxy endpoints
• You're comfortable with a third-party managing Zendesk auth
• You need features like macro execution and view queries that are tedious to build from scratch

When to prefer your own proxy (Path B):

• You need precise control over which data leaves Zendesk (compliance, data residency)
• You have complex custom ticket fields that community servers don't handle well
• You want lower latency (direct API calls, no intermediate MCP translation layer)
• Your team already has an API proxy pattern for other tools

Real Use Cases for a Zendesk + OpenClaw Agent

These are the workflows support teams actually run once the connection is working — specific to Zendesk's data model, not generic "ask questions about your tickets."

1. Morning Queue Triage

Every morning at 9 AM, OpenClaw queries Zendesk for all open tickets, groups them by priority and SLA risk, and posts to #support:

📋 Morning Queue — July 20 Total open: 47 tickets Urgent: 2 — Acme Corp (printer offline, 12 min SLA remaining), Beta Inc (API down, 28 min SLA remaining) High: 11 — 3 approaching first-reply SLA breach Normal: 29 — 7 with no response in 24+ hours Low: 5 — all within SLA Unassigned: 14 tickets — 3 urgent, 2 high

⚠️ SLA risk: 3 tickets will breach first-reply SLA within the next hour I can assign the unassigned urgent tickets to the on-call agent — want me to?

The agent queries tickets via search endpoint, pulls SLA timestamps from ticket_metrics, and cross-references with assignment data. Reps see the full picture before their first coffee — no Zendesk login required.

2. Customer 360 Before Every Reply

A support agent types "tell me about the person behind ticket #12345" in Slack. OpenClaw pulls:

• Requester profile (name, email, organization, role, timezone)
• Organization details (plan tier, custom fields, account manager)
• Full ticket history — all past tickets from this user across every channel
• Recent satisfaction ratings — CSAT scores from their last 5 resolved tickets
• Current open tickets — are they in multiple queues?
• SLAs — is this ticket at risk of breaching?

All returned in a single Slack thread. Multiple API calls happen — user lookup, organization lookup, ticket history search, satisfaction ratings, ticket_metrics — but the agent handles the orchestration. The agent gets a complete customer dossier without hunting through Zendesk views.

3. SLA Breach Early Warning

Every 30 minutes, the agent checks for tickets approaching SLA breach thresholds and posts to #support-leads:

🔴 SLA Breach Risk — 3 tickets

1. #12345 — Acme Corp — Urgent, first reply SLA: 7 min remaining. Assigned to: Jane. Unclaimed.
2. #12401 — Beta Inc — High, next reply SLA: 18 min remaining. Assigned to: Mike. Last agent reply: 3h ago.
3. #12422 — Gamma Ltd — Normal, resolution SLA: 42 min remaining. Assigned to: Sarah. Customer replied 1h ago — waiting on agent.

Should I escalate #12345 and #12422 to the team leads?

This uses Zendesk's ticket_metrics API — specifically the reply_time_in_minutes and requester_wait_time_in_minutes fields — to calculate remaining SLA headroom. The agent knows the difference between "agent hasn't replied yet" (first reply SLA) and "customer is waiting for our next response" (next reply SLA) — two completely different breach calculations.

4. Weekly Support Analytics

Every Friday at 4 PM, the agent generates a support team report from Zendesk data:

📊 Support Week 29 — July 13-19 Tickets created: 312 (+12% vs last week) Tickets resolved: 298 Avg first reply time: 2.1 hours (SLA target: 4h ✅) Avg resolution time: 18.4 hours (SLA target: 24h ✅) SLA breaches: 4 (3 first-reply, 1 resolution) — all on Tuesday during the API outage spike CSAT: 92% (avg of 178 ratings) Top ticket drivers:

1. "Password reset" — 47 tickets (up from 28 last week — knowledge gap?)
2. "API integration" — 41 tickets
3. "Billing question" — 34 tickets

🔍 Anomaly: "Password reset" tickets doubled week-over-week. Did the new SSO rollout cause confusion? I can search the help center for outdated password docs if you want.

The agent queries ticket counts and aggregations via search, SLA stats from ticket_metrics, CSAT from satisfaction_ratings, and uses tag frequency analysis to surface top ticket drivers. This is not a generic "AI wrote your weekly report" — it's a data pull with anomaly detection and actionable follow-up questions.

5. Cross-Tool Incident Response

When a production incident is declared in your monitoring tool, the agent cross-references across systems:

1. Zendesk: How many tickets mention the same error message? Are they from enterprise customers?
2. GitHub: Is there a recent deploy that could have caused this? Are there open issues?
3. Slack: Are users complaining in community channels?
4. Status page: Is the incident already public?

The agent queries all four sources through separate MCP servers and posts a consolidated incident brief:

🚨 Incident — "API 503 errors" Zendesk: 23 tickets in the last 15 min (5 enterprise, 3 urgent). Top tag: "api-errors" GitHub: Deploy #4732 (v2.14.1) landed 22 min ago — rate-limiter middleware was changed Slack: #api-users and #enterprise-support channels lighting up — enterprise customer Delta Inc threatening to escalate Status page: Not yet updated — should I draft the incident post? Recommended action: Roll back deploy #4732, update the status page, send a mass reply to affected Zendesk tickets

This works because OpenClaw + Cody can consume multiple MCP servers simultaneously — Zendesk, GitHub, Slack — and let the model reason across contexts. No support agent needs to switch between four tabs to piece together what's happening.

Zendesk-Specific Pitfalls (What Most Guides Miss)

These are the real-world gotchas from teams running Zendesk integrations in production:

1. SLA Data Lives in a Separate API

The ticket object doesn't include SLA timestamps. If you query /api/v2/tickets/12345, you get subject, status, priority, assignee, tags, custom fields — but no SLA breach information. That data lives in /api/v2/ticket_metrics, and it's per-ticket (no bulk endpoint). To build a queue view with SLA risk indicators, you need one ticket_metrics call per open ticket. For a queue of 47 tickets, that's 47 additional API calls every time you refresh. Fix: Cache ticket_metrics data with a 5-minute TTL. Use the search endpoint's sla_breach computed attribute (if available on your plan) to pre-filter. Consider switching to webhook-driven SLA updates instead of polling.

2. Search Pagination Is Cursor-Based, Not Offset-Based

Zendesk's search API uses cursor tokens, not page numbers. The response includes a next_page URL that you must follow exactly — you can't skip to page 5. If you have 10,000+ tickets and want the ones at the bottom, you're following the cursor chain. Fix: For queue views, use saved Zendesk views (which are pre-computed) rather than raw search. For historical analysis, use the Incremental Export API (/api/v2/incremental/tickets.json?start_time=...) which is designed for bulk data pulls and supports time-range paging.

3. Rate Limits Are per-Plan, Not per-Token

Zendesk's standard rate limit is 700 requests per minute for most plans, but it's shared across all API tokens from the same account. If your OpenClaw agent is querying tickets while a reporting dashboard is hitting the same API, you'll hit the limit faster than expected. Fix: Monitor the X-Rate-Limit-Remaining header in your proxy. Build retry logic with exponential backoff. If your team needs higher throughput, Zendesk offers API rate limit increases on Enterprise plans.

4. The MCP Server and MCP Client Are Different Things

Zendesk's MCP Client (early access, June 2026) lets Zendesk AI Agents connect outward to external tools — think "Zendesk AI Agent queries your order management system via MCP." The MCP Server (coming summer 2026) lets external AI systems connect inward to Zendesk data — think "OpenClaw queries Zendesk tickets via MCP." They solve opposite problems, and search results frequently conflate them. Fix: For OpenClaw → Zendesk, you need the MCP Server, which isn't generally available yet. Until then, use Path B (API proxy) or Path C (community servers). Do not try to use the MCP Client — it goes the wrong direction.

5. Ticket Comments Have a Complex Threading Model

Zendesk tickets don't have a flat list of comments. They have:

• Public replies — visible to the requester
• Internal notes — visible only to agents
• System events — status changes, assignment changes, tag updates
• Voice/chat transcripts — stored as special comment types
• Satisfaction survey responses — attached to the ticket but not in comments

When your agent says "summarize this ticket thread," it needs to decide which comment types to include. A customer doesn't see internal notes; a manager needs to. Fix: In your proxy, expose a comments endpoint that accepts a visibility parameter (public, all, system_events). Tag each comment with its type in the response. Let the agent or user choose what context is appropriate.

6. Custom Ticket Fields Need Explicit Discovery

If your Zendesk instance has custom ticket fields (and most do — "Product Area," "Customer Tiers," "Bug Severity"), they won't appear in default API responses with human-readable names. You get custom_field_12345678: "value" — not product_area: "Billing". Fix: During setup, call /api/v2/ticket_fields to build a field ID → name map. Store it in your skill file or proxy config. Your proxy should translate field IDs to names in responses before sending to OpenClaw. Without this, your agent is blind to your team's most important classification data.

7. The "Views vs Search" Decision Makes or Breaks Performance

Zendesk offers two ways to query tickets: Views (pre-computed, cached ticket lists defined in the Zendesk UI) and Search (live, dynamic queries via the search API). Views are fast but static — they reflect the saved view definition, which may not match your agent's question. Search is dynamic but slow for large datasets. Fix: Use Views for standard queue queries ("show me the Backlog view") because they're instant and don't consume API rate limit. Use Search only when you need dynamic filtering that Views can't express ("show me tickets tagged 'bug' AND 'api' created by enterprise customers this week").

Zendesk API Endpoint Reference

The key endpoints your OpenClaw proxy needs — based on Zendesk's v2 REST API:

Header to watch: All responses include X-Rate-Limit-Remaining — your proxy should log this and slow down if it drops below 50.

Decision Matrix: Which Path Should You Take?

Related Pages

• Cody AI Assistant for Zendesk — Cody's dedicated Zendesk integration features
• How to Connect Zendesk to ChatGPT — connecting Zendesk to ChatGPT
• How to Connect Intercom to OpenClaw — alternative support platform integration
• How to Connect HubSpot to OpenClaw — CRM + ticketing integration
• Zendesk AI Automation — AI automation workflows for Zendesk teams

What “Connect Zendesk to OpenClaw” Actually Means

In practice, connecting Zendesk to OpenClaw usually involves four layers:

• Authentication so OpenClaw can securely access Zendesk
• Tooling or proxy endpoints that expose the right Zendesk actions and data
• Skills/instructions that tell OpenClaw how to reason over Zendesk context
• Model selection so the assistant uses the right LLM for the job

That last piece matters more than most people expect.

Which Models Can You Use?

OpenClaw is model-flexible, so a Zendesk integration does not need to be tied to a single provider. Depending on your setup, teams commonly want to use:

• OpenAI models for broad reasoning, structured extraction, and tool use
• Anthropic models for writing, analysis, and long-context work
• Google models for multimodal and large-context workflows
• Other model backends if your OpenClaw environment exposes them

Model names and availability change frequently, so check your OpenClaw model catalogue rather than copying a version from a guide. The practical point is that you can connect Zendesk once, then choose a supported model for each workflow.

For example:

• Use Claude for nuanced summarisation or drafting
• Use OpenAI for structured extraction, tool-heavy workflows, or general-purpose copiloting
• Use Gemini when multimodal or very large context windows matter

A Good Integration Pattern for Zendesk

A strong Zendesk + OpenClaw setup usually looks like this:

1. OpenClaw receives a request in chat or from an automation
2. It calls the right Zendesk endpoint or proxy
3. The selected model reasons over the returned context
4. OpenClaw returns an answer, draft, classification, or action
5. High-risk actions stay behind approvals or structured guardrails

That is what makes the setup operational rather than just experimental.

Step-by-Step: Connect Zendesk to OpenClaw

Step 1: Create a Zendesk API Token

Go to Zendesk Admin → Apps & Integrations → APIs → Zendesk API and enable token access. Generate a token. Authentication uses HTTP Basic with your agent email address and the token as the password (formatted as email/token:your_token). Your API base is https://{your-subdomain}.zendesk.com/api/v2.

Step 2: Use the Ticket Search Endpoint

The /api/v2/search.json?query=... endpoint supports Zendesk's search syntax — filter by status, priority, assignee, requester, and more. This is your primary tool for queue queries. For individual ticket details, /api/v2/tickets/{id} gives you the full record including comments.

Step 3: Build the Proxy and Skill File

Build your proxy around search and ticket detail endpoints. Write ~/.openclaw/skills/zendesk.md with your SLA targets, common status filter patterns, and agent email-to-name mappings so Claude can present results naturally.

Model-Specific Workflow Ideas

Zendesk + OpenAI

Use this when you want a strong general-purpose setup for extraction, classification, action planning, and tool-driven workflows around Zendesk.

Zendesk + Claude

Use this when you want better writing quality, clearer summaries, stronger nuance, and reliable long-context reasoning over Zendesk data.

Zendesk + Gemini

Use this when the workflow benefits from large context windows, multimodal inputs, or Google-native ecosystem alignment.

Common Mistakes

Most teams do not fail because the model is bad. They fail because:

• the Zendesk connection is too thin
• the model lacks the right live context
• prompts are vague
• no structured outputs are enforced
• permissions and approvals are skipped
• one model is forced to do every job, even when another would be a better fit

The best setup is usually one integration layer, multiple model options, and clear guardrails.

Challenges and Caveats

Rate Limits Apply to All Plans

Zendesk API rate limits are 700 requests per minute for most plans (lower for legacy plans). If your integration is serving a busy support team with many concurrent Slack queries, monitor your usage.

SLA Data Requires the SLA API

SLA policy breach times are in a separate part of the API (/api/v2/ticket_metrics) — the main ticket endpoint doesn't include SLA timestamps by default. Your proxy will need an extra call for SLA-related queries.

Related OpenClaw Guides

• How to Connect Intercom to OpenClaw
• How to Connect Freshdesk to OpenClaw
• How to Connect HubSpot to OpenClaw

Looking for a more workflow-first angle? See: Zendesk AI Automation and Zendesk AI Assistant.

More Zendesk Resources

• Cody AI Assistant for Zendesk — Cody's dedicated Zendesk integration features and benefits