Zendesk for Developers
Four extension points, and picking the wrong one costs weeks. This is the orientation nobody gets before they open the Zendesk developer documentation.
The four things a Zendesk developer can build
Zendesk is not one platform. It's a helpdesk with four separate ways to extend it, and they barely share concepts.
Most requirements map cleanly onto exactly one of these. The expensive mistakes come from building an app when you needed a webhook, or polling the API when an event would have told you.
Apps: the agent-side surface
A Zendesk app is a small web application sandboxed in an iframe, positioned in the ticket sidebar, the top bar, or the modal layer. It talks to the host through a client library that lets it read the current ticket, react to interface events and write back through the API.
The constraint that shapes everything: it's an iframe. You get a narrow column, you cannot restyle the surrounding interface, and cross-origin rules apply. Requests to third-party services should go through the secure settings mechanism so credentials aren't sitting in client-side JavaScript.
Build an app when the agent needs context from another system while they work, or a one-click action that's specific to your business. Don't build one to change how Zendesk itself looks. See the apps and marketplace guide for distribution, and the app builder if a low-code route would do.
Themes: the customer-side surface
The help centre is templated with Handlebars, with a defined set of templates and a set of helpers and objects that expose your content. You edit the templates, the stylesheet and the theme JavaScript, then import the theme as a package or manage it from a Git repository.
Two things to know early. The available objects are fixed, so you can't render data the templating layer doesn't expose, and the workaround is usually client-side JavaScript calling the API, which has its own authentication implications on a public page. And upgrades to the stock theme don't flow into your fork, so a heavily customised theme is a maintenance commitment.
The Guide themes guide covers the workflow and the sandbox story properly.
Webhooks and the API: the integration surface
Webhooks are the right default for anything event-shaped. A trigger fires, Zendesk posts to your endpoint, your service does the work. That's cheaper than polling, faster, and it doesn't burn your rate limit.
Your endpoint must return quickly and handle being called twice for the same event, because at-least-once delivery is the normal assumption for any webhook system. Queue the work, respond immediately, make the handler idempotent. The webhooks guide covers signing and retries.
The REST API is for everything else: bulk operations, backfills, reporting extracts, anything where you're the one deciding when. Start with the Zendesk API guide for the base URL, the auth options and the resource families. And remember that the Sell API is an entirely separate surface with its own host and its own tokens, which catches people who assume one Zendesk account means one API.
Habits that save you later
Get a sandbox before you write anything. Testing a bulk update against a live queue is a decision people make exactly once.
Create a dedicated integration user rather than borrowing an agent account, so you can exclude it from notification triggers and read the audit log without guessing. Honour the rate limit headers and the Retry-After on a 429 rather than hard-coding a delay. And check whether an app already exists in the marketplace, because a maintained integration you configure beats one you own and have to keep alive.
Read the JSON format table for a resource before its endpoint list, too. It tells you which fields are read-only and which the system writes for you, and it answers most of the "why did my update do nothing" questions before you get round to asking them.
Frequently asked questions
Where does Zendesk development actually start?
With the extension point, not the code. The Zendesk developer platform offers apps, themes, webhooks and the REST API, and this Zendesk developer guide exists because picking the wrong one costs weeks.
Do I need an app or a webhook?
An app if an agent needs to see or do something inside the ticket interface. A webhook if another system needs to react when something happens in Zendesk.
What language does a Zendesk developer use for apps?
They are web applications, so HTML, CSS and JavaScript running in a sandboxed iframe, talking to the host through the apps client library.
Can I change the agent interface with a theme?
No. Themes are help centre only, which is the customer-facing side. Anything agent-facing is an app, and even then you are working inside an iframe.
Should I poll the API for new tickets?
Almost never. Use a webhook fired by a trigger for events, and the incremental export endpoints when you need to sync data in bulk.
Is the Zendesk Sell API part of the same platform?
No. Sell has its own base URL, its own OAuth tokens and its own response envelope. Support credentials won't authenticate against it.
The integration you don't have to build
Duplicate detection is a classic build-it-yourself project. Ticket Merger is that project, already finished.
Start free trial14-day free trial. No credit card required.