What Is the Zendesk API? A Plain-English Guide for Non-Developers (2026)

The Zendesk API is a REST interface at https://{subdomain}.zendesk.com/api/v2/ that lets other software create, read, update and delete the same tickets, users and organizations you see in Zendesk, with every response returned as JSON. You authenticate with OAuth, because Zendesk is retiring API tokens and will deactivate the last of them on 30 April 2027. Your plan caps you at between 200 and 2,500 requests a minute. You don't need to write code to understand it, and knowing these basics lets you evaluate vendors and brief a developer accurately. Details below are checked against Zendesk's developer documentation on 24 September 2026.

What is an API, in plain English?

Think of a restaurant. You sit at the table, read a menu and tell the waiter what you want. You never walk into the kitchen, and you don't need to know how it works. The waiter takes your order in a format the kitchen understands and brings back exactly what you asked for.

An API (application programming interface) is that waiter. It's a defined menu of requests one piece of software can make to another, and a defined format for the responses. When a tool "uses the Zendesk API," it isn't logging into the Zendesk website and clicking buttons. It sends structured orders straight to Zendesk's kitchen (create this ticket, give me this user, update this field) and gets structured answers back. No human, no browser, no clicking.

That's the point of it: the API lets other software do in Zendesk what a person could do in the interface, automatically, in bulk and much faster.

How is the Zendesk REST API organized?

Zendesk's main API is a REST API. "REST" is a common convention for organizing these menus: you act on things (called resources) with a small set of standard verbs, over the same web technology your browser uses (HTTP).

The resources are the objects you already know from Zendesk: tickets, users, organizations, groups, macros, views, articles and so on. The verbs map to plain actions, usually summarized as CRUD:

• Create: make a new ticket, add a user (HTTP POST)
• Read: fetch a ticket, list your organizations (HTTP GET)
• Update: change a ticket's status, edit a field (HTTP PUT)
• Delete: remove a record (HTTP DELETE)

Two more facts make it concrete. First, every request goes to a base address built from your account's subdomain:

https://{subdomain}.zendesk.com/api/v2/

If your Zendesk lives at acme.zendesk.com, your API base is https://acme.zendesk.com/api/v2/. Add the resource to the end: https://acme.zendesk.com/api/v2/tickets.json lists tickets, .../users.json lists users. The /v2 is the API version, and .json signals the format.

Second, the API speaks JSON (JavaScript Object Notation), a readable way of writing data as labeled key-value pairs. When you read a ticket, Zendesk doesn't send a web page. It sends a JSON object describing that ticket, and you'll see one below.

How do you authenticate with the Zendesk API?

The API will do almost anything a person can, so it has to know who's asking. The options changed in 2026, and the change decides what a new integration should use.

1. OAuth access tokens (the method Zendesk recommends, and the one to build on). OAuth issues a token tied to a specific connected app, sent as Authorization: Bearer {access_token}. Access can be scoped and revoked cleanly, and Zendesk's security and authentication docs tell existing customers on API tokens that they "will have to migrate to OAuth access tokens." Apps distributed to many Zendesk customers must use global OAuth tokens.

2. API tokens (being retired). An API token is a secret an admin creates in Admin Center, combined with an agent email in the form below and sent over HTTP basic authentication:

[email protected]/token:THE_API_TOKEN

A token can act as anyone in the account, including admins, which is why Zendesk is removing them in three phases (Zendesk announcement):

• From 28 July 2026: tokens unused for 30 days are deactivated, tokens deactivated for 60 days are deleted, and accounts created on or after that date can't create or use API tokens at all.
• From 27 October 2026: no account can create new API tokens.
• On 30 April 2027: all remaining API tokens are deactivated permanently.

The removal covers the Ticketing, Help Center and Voice APIs; tokens for Messaging and Chat aren't part of it. We cover the switch in more depth in why Zendesk OAuth is now the default.

3. Email and password (removed). Zendesk stopped offering password access to new accounts on 31 July 2024 and began removing it from all remaining accounts on 12 January 2026. If a vendor still asks for an agent's password to connect to the API, that integration no longer works.

The practical rule for non-developers: anything you set up today should use OAuth. If an existing script or vendor still runs on an API token, ask for its migration plan before 30 April 2027.

What does a real Zendesk API request look like?

Here's a request that lists tickets using an OAuth access token. curl is a command-line tool for making web requests. You don't need to run it, but seeing it shows what "calling the API" means:

curl https://acme.zendesk.com/api/v2/tickets.json \
  -H 'Authorization: Bearer YOUR_ACCESS_TOKEN'

That's all it is: the base URL, the tickets.json resource, and the access token in a header. Zendesk replies with JSON. A trimmed response looks like this:

{
  "tickets": [
    {
      "id": 35436,
      "subject": "Refund request for order #1290",
      "status": "open",
      "priority": "high",
      "requester_id": 20978392,
      "assignee_id": 235323,
      "tags": ["refund", "vip"],
      "created_at": "2026-06-18T14:02:11Z"
    }
  ],
  "meta": { "has_more": true, "after_cursor": "xkq3..." },
  "links": { "next": "https://acme.zendesk.com/api/v2/tickets.json?page%5Bafter%5D=xkq3..." }
}

Each ticket is a set of labeled fields (id, subject, status, priority, tags), the same properties you see on the ticket's right-hand panel in the Zendesk ticketing interface, expressed as data. The meta and links sections at the bottom are for pagination.

How does Zendesk API pagination work?

Your account might hold hundreds of thousands of tickets. No single response hands them all over, because it would be enormous and slow. The API returns one page at a time and tells you how to fetch the next, like clicking "next" through search results.

Zendesk recommends cursor-based pagination. You ask for a page size (page[size], up to 100 records on most endpoints), and each response includes a links.next URL plus a meta.has_more flag. While has_more is true, you follow links.next; when it's false, you've reached the end. The cursor is a bookmark pointing at where the next page begins, which keeps it fast and consistent across millions of records, with no depth limit.

The older offset style (page and per_page parameters) is capped at the first 100 pages or 10,000 records; since 15 August 2023, requests beyond that return a 400 Bad Request error (Zendesk pagination docs). If a vendor says its integration "only syncs the first 10,000 tickets," that's an offset-pagination limit, and a sign it should be using cursors.

What are the Zendesk API rate limits?

Zendesk limits how many API requests an account can make per minute. Go over and the API returns a 429 Too Many Requests response with a Retry-After header saying how many seconds to wait. This is where well-meaning integrations get into trouble, so it's worth understanding even if you never touch code.

The allowance depends on your plan. Zendesk's documented Support API account limits, checked 24 September 2026:

The High Volume API add-on raises a qualifying plan to 2,500 requests a minute. It's available on Suite Growth and above (and Support Professional and above), with a minimum of 10 agent seats. Some endpoints carry their own tighter limits: incremental exports allow 10 requests a minute (30 with the add-on), and ticket updates are capped at 100 requests a minute per account (300 with the add-on) and 30 updates per 10 minutes per user on a single ticket.

Zendesk revises these numbers, and they differ by product (Support, Help Center, Chat), so confirm the current figures in Zendesk's rate-limit documentation before sizing a project. The principle stays fixed: there's a ceiling, and good software respects it.

In practice, any integration worth trusting must handle 429s gracefully: back off, wait the Retry-After interval and retry, rather than hammering the API. When an import tool or sync "randomly stalls," an unhandled rate limit is the usual cause.

What should you ask a vendor about their Zendesk integration?

A few habits separate a sturdy integration from a fragile one. Knowing them lets a non-technical owner ask a vendor the right questions:

• Does it handle 429s and respect Retry-After? Retrying immediately makes the problem worse.
• Does it use sideloading to cut request counts? Instead of fetching a ticket and then separately fetching its requester, the include parameter returns related records in one call: GET /api/v2/tickets.json?include=users,groups returns the tickets and their users and groups together. Fewer round trips keep you under the rate limit.
• Does it use the Incremental Exports API for bulk reads? When you need everything (a migration, a nightly sync), the incremental export endpoints return records changed since a given time and are built for volume, instead of paging through the normal list endpoints.
• Is it on OAuth? An integration still on an API token has a hard stop on 30 April 2027.

What can you do with the Zendesk API?

The Zendesk API lets software read and write nearly every object in your account: tickets, comments, users, organizations, groups, tags, custom fields, macros, views and Help Center articles. Real-world uses fall into four groups:

• Integrations. Connect Zendesk to the rest of your stack: push tickets into a CRM, sync customers from billing, mirror conversations into a data warehouse.
• Migrations. Move tickets, users and knowledge content into or out of Zendesk when switching tools or merging accounts. Migration vendors run almost entirely on the API.
• Custom apps and internal tools. A tailored dashboard, a self-service flow on your own website, or an internal admin tool that creates and updates tickets behind the scenes.
• Bulk updates. Re-tag thousands of old tickets, reassign a departing agent's queue, or mass-update a custom field, which would take days by hand.

A close cousin: webhooks. The API is pull (your software asks Zendesk for data); webhooks are push (Zendesk notifies your software when something happens). Real integrations usually combine both. We cover the push side in Zendesk webhooks explained.

When should you use the API instead of native Zendesk features?

The API is code someone has to build and maintain. Reach for native features first when they'll do the job:

• Triggers, automations and macros handle most in-Zendesk logic (auto-replies, routing, field changes) with no code.
• Marketplace apps already cover popular integrations (Slack, Jira, Salesforce, Shopify). Install before you build.
• Webhooks plus triggers send data out on events without a custom polling script.

Use the API when native tools fall short: a system with no ready-made integration, a migration, a bulk operation, or a custom experience you're building yourself. Configure before you integrate, and integrate before you build.

How do AI agents use the Zendesk API?

AI is a growing consumer of the Zendesk API. The API exposes tickets, users and fields as structured data and lets software act on them, which is what automation needs to do more than suggest replies.

An AI agent layer like Macha sits on top of your existing Zendesk rather than replacing it, and uses the API and webhooks to take real actions: read an incoming ticket, classify and tag it, look up data in connected systems, draft a reply, route it to the right group, or resolve routine requests. The difference from a script you'd build yourself is that you configure these behaviors instead of coding API calls, OAuth and rate-limit handling by hand.

It's another integration to manage, and it performs only as well as the knowledge and rules you connect. Macha bills per ticket: one conversation, charged once however many automated steps it takes and whichever model it runs on, not per resolution, so the bill doesn't hang on an outcome definition you don't control. Pricing starts at $299 a month for 750 tickets, about $0.40 each, with setup and monitoring by the Macha team included. You can try it with $50 of free usage, no credit card required.

Frequently asked questions

What is the Zendesk API? A REST API that lets other software read and write data in your Zendesk account (tickets, users, organizations, fields and more) without the web interface. Requests go to https://{subdomain}.zendesk.com/api/v2/ and responses come back as JSON. It's how integrations, migrations and custom tools talk to Zendesk.

How do I authenticate with the Zendesk API? Use an OAuth access token, sent as a Bearer token; Zendesk recommends it and is moving everyone to it. API tokens ([email protected]/token:THE_TOKEN over basic auth) still work on older accounts but are being retired, and email/password access for the API was removed in January 2026.

Are Zendesk API tokens being removed? Yes. From 28 July 2026, unused tokens are deactivated after 30 days and new accounts can't use tokens; from 27 October 2026 no one can create new tokens; and on 30 April 2027 all remaining tokens are deactivated permanently. Any script or vendor still on a token needs to move to OAuth before then.

What are the Zendesk API rate limits? Between 200 requests a minute on Team and 2,500 on Enterprise Plus, with the High Volume API add-on lifting qualifying plans to 2,500 and tighter limits on some endpoints. Over the limit you get a 429 response with a Retry-After header. The numbers change, so confirm current values in Zendesk's developer docs.

How does Zendesk API pagination work? List endpoints return one page at a time. Zendesk recommends cursor-based pagination: request a page[size] (up to 100), then follow links.next while meta.has_more is true. The older offset style stops at 10,000 records and returns a 400 error beyond that.

Do I need to be a developer to use the Zendesk API? To write your own integration, yes, or you'll need one. You don't need to code to use what the API powers: most teams rely on Marketplace apps, migration tools or an AI layer that calls the API for them. Knowing the basics helps you evaluate those tools and brief a developer.

What's the difference between the Zendesk API and webhooks? The API is pull: your software requests data when it wants it. Webhooks are push: Zendesk sends your software a message when an event happens. Sturdy integrations usually use both. See Zendesk webhooks explained.

Where should a non-developer start with the Zendesk API?

Start with the three facts that decide whether an integration will hold up: it should sign in with OAuth, read data with cursor pagination, and back off when it hits your plan's per-minute limit. Use the API when triggers, macros and Marketplace apps can't do the job. From here, see the push side in Zendesk webhooks explained, and how teams put it to work in how to automate Zendesk with AI.

Zendesk REST API facts checked against Zendesk's developer documentation and Zendesk's API token announcement on 24 September 2026. Rate limits are plan-dependent and change periodically, so confirm current figures for your plan before relying on them.