Integrator for Zendesk
Integrating the Zendesk API into your system
We wire Zendesk into your business application: tickets, users and organizations both ways, with product context on every case.
- Senior product team
- support connectors in production
- from scoping to monitoring
Why work with a Zendesk integrator and what can be connected to Zendesk?
Zendesk is one of the most widely used customer support platforms by growing companies for centralising client requests. A Zendesk integrator connects Zendesk to your application, CRM or data warehouse so tickets are automatically created with the full account context, updates in Zendesk are reflected in your software, and support data feeds your reporting. The work involves maintaining identifier consistency between Zendesk and your other systems, and preventing internal automations from overwriting each other.
What a Zendesk integrator unlocks
Application incident, named ticket
Created from your product, external_id = incident id, organization = customer account. The agent and the user talk about the same file.
Status mirror in the portal
Requests API for the end-user, Tickets API for the internal agent. open, pending, solved: the customer sees state without opening Zendesk.
Support analytics warehouse
Incremental Tickets + Users, cursor, without burning the agent's quota. SLA, queues, CSAT in your BI, not in a Friday CSV export.
Users aligned with the CRM
Zendesk records follow the CRM without creating duplicates. Agent and sales talk about the same account.
What this changes in your support
Engineering in service of a measurable outcome: a ticket without collision, product context, BI without CSV.
No more agent overwrites
When a Zendesk rule and your connector touch the same ticket, neither overwrites the other. The case stays coherent.
Support BI without Friday exports
Tickets and users feed your warehouse as they change. SLAs, queues and CSAT live in your BI.
The customer portal stays smooth
Updates are batched. You avoid saturating Zendesk during an escalation and blocking agents.
The Zendesk plan is scoped in the quote
Call volume depends on the Suite tier. We size the connector on your real plan, not an unlimited demo.
How we ship your Zendesk connector
Scoping
Which flows, Tickets or Requests, real Suite plan, High Volume or not, GDPR (user = person). We list edge cases before writing a line of code.
Development
HMAC TIMESTAMP + raw body, Incremental cursor, per-user queue at 5 / min, aggregated ticket updates. Token bucket aligned on the plan.
Testing
Automation vs connector collision, SCRUBBED ticket, time-based duplicates, documented test secret. We replay the 429 on ticket update.
Monitoring
X-Rate-Limit, Retry-After, TooManyJobs, webhook invocations. You know a flow is broken before your agents do.
What the Zendesk API allows
- Tickets and Requests
- CRUD, create_many, merge, CCs, followers, custom fields, external_id. Statuses new, open, pending, hold, solved, closed. Types problem, incident, question, task.
- Users and organizations
- End-users, agents, admins. POST /api/v2/users/create_or_update at 5 / min / user. Incremental user export, same discipline as tickets.
- Incremental Export
- Cursor recommended for tickets and users. Time-based: expected duplicates, no gaps, last minute excluded. Deleted tickets stay exported, then SCRUBBED, then drop around 120 days.
- Signed webhooks
- CRUD, invocation monitoring. X-Zendesk-Webhook-Signature = base64(HMACSHA256(TIMESTAMP + BODY)). Trial: 10 webhooks, 60 invocations / min.
Zendesk API vocabulary
- Tickets vs Requests
- Tickets: agent view, private comments included. Requests: end-user view, public comments only. A connector that mixes the two leaks internal notes.
- safe_update
- Conditional update with updated_stamp. Without it, an automation and your connector overwrite each other. That is the detail that separates a PoC from a multi-agent connector.
- Incremental Export
- Cursor-based recommended. Time-based: filter id+updated_at (duplicates), resume from end_time (no gaps), last-minute data excluded. This is not a paginated list.
- X-Zendesk-Webhook-Signature
- base64(HMACSHA256(TIMESTAMP + BODY)), plus X-Zendesk-Webhook-Signature-Timestamp. Public test secret: dGhpc19zZWNyZXRfaXNfZm9yX3Rlc3Rpbmdfb25seQ==.
- external_id
- Link between the Zendesk ticket and the business object (order, job site, serial number). Idempotency key at create time.
- High Volume API
- Add-on that raises the cap to 2,500 / min (Growth+ / Support Professional+, 10 seats min). It is not a bonus stacked on the Suite quota.
The real constraints of the Zendesk API
30 updates / 10 minutes / ticket / agent
Plus 100 / min / account (300 with High Volume). A naive escalation workflow saturates this cap. We aggregate patches. This is the most misdiagnosed 429.
List all tickets is not the sync tool
Past page 500: 50 / min. The Tickets docs point to Incremental Export. A daily job on GET /tickets?page= is a documented anti-pattern.
create_or_update: 5 / min / user
Update User and create_or_update share this bucket. A CRM backfill is queued per user. Incremental users: 10 / min (30 with High Volume).
tags replaces the whole set
A naive PUT wipes tags set by agents. We re-read before write, or we send tags only when that is the intent. description is read-only; comment writes the first message.
Zendesk API or Freshdesk API?
Two enterprise helpdesks. Zendesk weighs on export, safe_update and webhooks; Freshdesk on simpler CRUD and automations.
| Criterion | ZendeskThis page | FreshdeskFreshworks helpdesk |
|---|---|---|
| Tickets | new/open/pending/hold/solved/closed | Numeric statuses 2/3/4/5 |
| Stock sync | Incremental Export (cursor) | Paginated list, include billed |
| Webhooks | API + HMAC SHA-256 | Automations, no dedicated v2 bus |
| Quota | 200 to 2,500 / min by Suite plan | Read from X-RateLimit-Total |
| Identity | Users, create_or_update 5 / min / user | Contacts + Agents, 409 duplicate |
| Anti-collision | safe_update + updated_stamp | Business idempotency |
| The right case | Enterprise support, warehouse, multi-agent | Freshworks helpdesk already in place |
The three (Zendesk, Freshdesk, Intercom) are not the same connector. Zendesk requires incremental export and safe_update. Freshdesk bills include. Intercom splits conversation and ticket. This is a scoping trade-off.
What we measure on a Zendesk integration
The other support APIs
If Zendesk is not the right foundation, these options are discussed at scoping.
ZendeskIntegrating the Zendesk API into your systemThis page
Freshdeskv2 tickets, contacts, billed include, automations rather than an event bus.
IntercomConversations and tickets, EU region, SHA-1 webhooks via the Hub.We combine Zendesk with
The stack around Zendesk on our projects.
Zendesk integrator: your questions
A Zendesk integrator links Zendesk to your application, CRM and warehouse, rather than pasting a widget. API integration: OAuth Bearer or Basic email/token auth, ticket create with external_id, safe_update on every PATCH shared with automations, Incremental Export cursor for stock, HMAC webhooks for real time. We do not build a job on GET /tickets?page=. The hard part is not CRUD, it is the 30 updates / 10 min / ticket cap and the Suite bucket shared with the UI.
Align the token bucket on the real plan (Team 200, Growth and Professional 400, Enterprise 700, Enterprise Plus or High Volume 2,500 / min). Aggregate ticket updates under 30 / 10 min / agent. Per-user queue at 5 / min on create_or_update. Incremental at 10 / min (30 with High Volume). Read X-Rate-Limit and Retry-After. High Volume raises the cap to 2,500, it is not a stacked bonus. Help Center has a separate bucket.
Because the Tickets documentation points to Incremental Export, and the list past page 500 drops to 50 / min. Cursor-based export is built for stock: filter time-based duplicates (id + updated_at), no gaps if you resume from end_time, last-minute data excluded. Deleted tickets stay exported, then SCRUBBED, then drop around 120 days. A warehouse that ignores SCRUBBED is no longer a KYC source. That is the official page, rarely read end to end.
A first useful flow, typically creating a ticket from an application incident with external_id, ships in two to three weeks. A chain with webhooks, incremental, CRM upsert, Requests portal and automation anti-collision is closer to six to eight weeks: organization mapping and GDPR weigh as much as the code. safe_update is in the first increment, not a later fix. We scope the perimeter up front and give a firm estimate before starting.
Zendesk if enterprise support is already the system of record, and you want a warehouse plus a signed event bus. Freshdesk if the Freshworks helpdesk is in place and ticket + contact CRUD is enough, with automations. Intercom if the product lives in Messenger, Inbox tickets beside conversations, EU region. Treating the three as the same connector is the scoping trap: incremental export, billed include, and SHA-1 webhooks are not interchangeable details.
A Zendesk integrator project?
Let's talk. 30 minutes to scope your tickets, incremental export, and to tell you frankly what is feasible.
Discuss my Zendesk project