What Is ZIS (Zendesk Integration Services)? A Plain-English Guide
If you've spent any time in Zendesk's developer documentation, you've probably tripped over a four-letter acronym that's never quite explained in plain language: ZIS, short for Zendesk Integration Services. It sounds like it should be the one feature that connects Zendesk to everything — and in a way it is, but it's also the most developer-facing corner of the platform, and the most easily confused with the half-dozen other ways Zendesk lets you extend it.
This guide is the plain-English version. We'll cover what ZIS actually is, the specific problem it solves, the core pieces you'll meet if you build with it, and — the part most articles skip — a clear, side-by-side answer to "which Zendesk integration tool do I use when?" ZIS sits next to plain webhooks, the REST API, the App Framework, and the Marketplace, and knowing the difference saves you from building the wrong thing. Everything here is verified against Zendesk's official developer docs.
What ZIS is, in one paragraph
In Zendesk's own words, ZIS is "a group of services that simplify building and running an integration for Zendesk." The key word is running. ZIS is a serverless, Zendesk-hosted integration framework: you write the logic for an integration as configuration and small JSON definitions, hand it to Zendesk, and Zendesk's infrastructure executes it for you. There's no server, container, or middleware for you to stand up, scale, or keep alive. As the docs put it, ZIS is "hosted and executed by Zendesk, reducing the need to host integration middleware," which lowers the risk, complexity, and cost of running an integration.
So ZIS is not a button in the agent interface and not something most support admins will ever touch directly. It's a developer platform — the plumbing Zendesk itself uses to build some of its bigger prebuilt integrations (Salesforce, Shopify, and others all run on ZIS under the hood).
The problem ZIS solves
To see why ZIS exists, picture the "before" version. Say you want this: whenever a ticket is created in Zendesk, look up the customer in your billing system and post a summary to a Slack channel.
Without ZIS, the classic recipe is: register a webhook so Zendesk POSTs ticket events to a URL you own, then stand up a small server (or a cloud function) at that URL to receive the event, call your billing system's API, call Slack's API, handle retries when something times out, store the credentials for all three systems somewhere secure, and then keep that service running and patched forever. The integration logic is maybe 30 lines. The infrastructure around it is the real work — and the real ongoing cost.
ZIS collapses that. You still describe the same flow — "on ticket created, do these steps" — but you describe it to Zendesk, and Zendesk runs it on its own infrastructure. No endpoint to host, no servers to babysit, and a built-in, encrypted place to store the API credentials each step needs. That's the whole pitch: integrations without standing up your own backend.
The core pieces of ZIS
Zendesk's docs break ZIS into five core services, with a workflow engine running on top that actually executes your logic (Understanding ZIS). You don't have to master all of them on day one, but these are the nouns you'll keep seeing.
The five services:
- ZIS Registry. The top-level container. You register a named integration, and the Registry stores its definition — the flows and the rules (JobSpecs) that tie them to events. Everything else hangs off this.
- ZIS Connections. Securely stores and manages the API credentials — OAuth tokens, API keys — for both Zendesk and the third-party systems your flow talks to. This is a big part of the value: you're not writing your own secrets vault.
- ZIS Configs. Stores per-account configuration — the settings a given customer's install needs.
- ZIS Links. Stores relationships between entities — for example, remembering that this Jira issue corresponds to that Zendesk ticket so a two-way sync knows what maps to what.
- ZIS Inbound Webhooks. The front door for external events: it lets a third-party system trigger a ZIS workflow by POSTing to a ZIS endpoint (rated up to 2,000 requests/minute, per the ZIS FAQs).
On top of those services sits the workflow engine, which runs your flows when a JobSpec says to:
- Flows. A flow is the actual logic, written as a JSON state machine (based on Amazon States Language — the same model behind AWS Step Functions). Each "state" is a step: make an HTTP request, transform some data, branch on a condition, loop over a list. The engine walks the states in order. Practical guardrails to know: a flow has a 100-second execution limit and a cap of 250 state transitions, so flows are for orchestration, not long-running batch jobs (flow states reference).
- JobSpecs. A flow doesn't run on its own; a JobSpec tells ZIS which event should kick off which flow — Zendesk's docs describe it as the object that "tells ZIS which trigger event to listen for, and which flow to run when that event occurs" (JobSpec reference). Conceptually it's a tiny JSON object — roughly
{ "event_source": "support", "event_type": "ticket.TicketCreated", "flow_name": "...notify_slack" }— read as "when a ticket is created, run the notify_slack flow."
Flows fire in response to events: native Zendesk events (changes to Tickets, Users, Organizations, or Sunshine custom objects), third-party events delivered through the Inbound Webhooks service, or custom Zendesk events. One important behavior: Zendesk events are delivered at least once, so a flow can occasionally run twice for the same event — well-built flows are written to be idempotent.
Put together, the flow of control looks like this:
- An event happens — a ticket is created in Zendesk, or an external system POSTs to your ZIS Inbound Webhook.
- A JobSpec catches it — it matches the event type and names the flow to run.
- The workflow engine runs the flow — stepping through the JSON state machine on Zendesk's servers.
- The flow pulls credentials from ZIS Connections — no secrets handling of your own.
- The flow calls the external API (Slack, your billing system, Jira) and/or the Zendesk API to finish the job.
No backend of yours involved at any step.
Which Zendesk integration tool, when?
This is the section worth bookmarking. Zendesk gives you several ways to extend it, and they're easy to conflate. Here's how ZIS relates to each — and when you'd reach for one over another.
| Tool | What it is | Where it runs | Reach for it when… |
|---|---|---|---|
| REST API | Request/response interface to read and write Zendesk data | Your code calls it, from anywhere | You need to pull or push data on demand from your own app or script |
| Webhooks | Outbound HTTP POST when something happens in Zendesk | Zendesk sends; you host the receiver | You want a notification elsewhere and already have (or want) your own endpoint |
| App Framework (ZAF) | Front-end apps embedded in the agent interface | In the agent's browser | You need UI — a sidebar panel, a custom button, data shown inside a ticket |
| ZIS | Serverless workflow engine for integration logic | On Zendesk's infrastructure | You want event-driven, multi-step integration logic with no backend to host |
| Marketplace | Catalog of prebuilt, installable apps & integrations | Installed into your account | A vendor has already built what you need — install instead of building |
The distinctions that trip people up:
- ZIS vs. plain webhooks. A webhook only delivers an event — it POSTs to a URL, and you still have to host the thing at that URL that does the work. ZIS delivers and runs the work: the event triggers a flow that executes on Zendesk's side. If you only want to ping an existing system, a webhook is simpler. If you'd otherwise have to build a server to react to the webhook, ZIS replaces that server.
- ZIS vs. the API. The REST API is something you call from your own code; it's passive and request-driven. ZIS is event-driven and hosted — and it typically calls the API for you as steps inside a flow. Think of the API as the verbs and ZIS as the place those verbs get sequenced and run automatically.
- ZIS vs. the App Framework. The App Framework (ZAF) is about UI — apps that render inside the Zendesk agent interface and run in the browser. ZIS has no interface; it's pure back-end logic. They're complementary: a sophisticated app often uses an App Framework front end with a ZIS back end doing the heavy integration work behind it.
- ZIS vs. the Marketplace. The Marketplace is the result — prebuilt, installable integrations. ZIS is one of the tools used to build them. In fact, several of Zendesk's own Marketplace integrations are built on ZIS. If a Marketplace app already does what you need, install it; you only build with ZIS when nothing prebuilt fits.
What developers who've used ZIS report
ZIS is a back-end framework with no UI to screenshot, so the honest way to ground it is in what practitioners and Zendesk's own guidance say about building with it in the real world.
The recurring theme is that ZIS removes the hosting burden but not the engineering one. ONEiO's integration team, in a March 2026 write-up, frames self-built ZIS work plainly: even though "ZIS can simplify maintenance and reduce the overhead associated with running your own integration infrastructure," a self-built API or ZIS integration still means investing in "configuring and maintaining integrations" over time, which is why they steer maintenance-averse teams toward a managed layer (ONEiO, Petteri Raatikainen, Mar 12 2026). A 2026 Zendesk integration guide from Pluno is blunter about the trade-off, classing "custom REST API and ZIS builds" as high-effort work that "does need engineering, with monitoring plus runbooks included," and warning that with full custom control comes "total responsibility… webhooks fail silently while data quietly drifts" (Pluno AI, Zendesk Integration in 2026).
The learning curve is real but bounded. Zendesk positions ZIS as approachable for anyone with the right background — its docs note that "if you have some experience with JSON and APIs, you can start building with ZIS" — and it shipped a browser-based ZIS Playground specifically so developers can "quickly learn to use Zendesk Integration Services capabilities, resources, and syntax" (ZIS Playground). That a dedicated sandbox exists is itself a tell: the JSON-state-machine model takes some ramp-up.
The most candid real-world signal comes from Zendesk's own debugging guidance, which reflects the async nature of flows. Because flows run asynchronously off an event queue, Zendesk explicitly advises that "when building and testing new ZIS integrations, we recommend that you gradually ramp up the number of triggering events" to "detect bugs that may cause delays with a larger number of events" (ZIS FAQs). In practice that means debugging happens after the fact, through the integration log and a flow's ExecutionStates output rather than a live debugger — a different rhythm than developers used to synchronous, request/response code expect.
Net of all this: developers who've built on ZIS tend to reach for it when the workflow is genuinely event-driven and multi-system and they want Zendesk to host it — and reach for a Marketplace app or the App Framework when a prebuilt option fits or the need is really a UI inside the agent workspace.
Who ZIS is for (and who it isn't)
ZIS is squarely a developer and ISV tool. It's aimed at:
- Developers and technical admins building a custom, private integration for their own Zendesk account — connecting Zendesk to an internal system the Marketplace doesn't cover.
- Software vendors (ISVs) building integrations to distribute, who'd rather not operate hosting infrastructure for every customer.
A few honest limitations to weigh. Today ZIS is geared toward single-account, private integrations — public, broadly distributable integrations built entirely on ZIS aren't generally available yet. It carries real technical constraints (the 100-second flow limit, 250 state transitions, a 256KB event payload cap, and API rate limits that count against your account's overall quota). And because flows run asynchronously with at-least-once delivery, you have to design for variable latency and the occasional duplicate run. On availability, ZIS is included at no extra cost on select plans — private integrations can be created and used on Suite Growth/Professional/Enterprise and Support Professional/Enterprise — rather than being a paid add-on (ZIS FAQs).
The bigger honest caveat: most teams never need ZIS. If you're a support manager, not a developer, the practical path is almost always a prebuilt Marketplace app for popular tools, a webhook for simple notifications, or — for the AI and automation work people most often want — a tool that connects to Zendesk for you.
Where this leaves non-developers
ZIS is powerful precisely because it lets developers build deep, event-driven integrations without running a backend. But "without running a backend" still means someone writes JSON flows, wires JobSpecs, and maintains the integration. For a lot of teams, the thing they actually wanted wasn't an integration project at all — it was an outcome: tickets triaged, data looked up across systems, replies drafted, routine requests resolved.
That's the gap an AI agent layer like Macha fills. Macha isn't a help desk and it isn't a replacement for Zendesk — it runs on top of your existing Zendesk and connects to it for you, so you don't build (or maintain) the integration plumbing yourself. Connected to your tickets, knowledge, and other tools, it can automate the work — read and classify a ticket, look up data in another system, draft a reply, route it, or resolve routine requests end to end — while anything it can't handle stays a normal ticket for a human.
Worth being even-handed: it's still another vendor in your stack, and it only performs as well as the knowledge and rules you connect to it. On cost, Macha bills per AI action (any automated step — summarize, tag, look up, draft, or resolve — at 0.5–9 credits depending on the model you pick), not per closed ticket, because most automation is work done along the way, not a single "resolution." If the reason you were eyeing ZIS was "I want Zendesk to do more, automatically, without a dev project," that's the lighter-weight route — you can try it free: 7-day free trial, no credit card required.
Frequently asked questions
What is ZIS in Zendesk? ZIS (Zendesk Integration Services) is Zendesk's serverless, Zendesk-hosted framework for building integrations. You define an integration's logic as JSON "flows," tie them to events with JobSpecs, and Zendesk runs everything on its own infrastructure — so there's no server or middleware for you to host. It also stores the API credentials your integration needs.
Is ZIS the same as the Zendesk API? No. The Zendesk REST API is a request/response interface that you call from your own code. ZIS is an event-driven workflow engine that runs on Zendesk's servers and typically calls the API for you as steps inside a flow. The API is the building block; ZIS is where those calls get sequenced and executed automatically.
How is ZIS different from the App Framework? The App Framework (ZAF) builds front-end apps — UI that appears inside the Zendesk agent interface and runs in the browser. ZIS is back-end logic with no interface. They're complementary: an app can use a ZAF front end with a ZIS back end doing the integration work.
How is ZIS different from a webhook? A webhook just delivers an event by POSTing to a URL you host — you still have to build something at that URL to do the work. ZIS delivers the event and runs the work on Zendesk's infrastructure via a flow, so there's no receiver for you to build or host.
Do I need to host a server to use ZIS? No — that's the main point. ZIS is serverless and hosted by Zendesk. You provide the configuration and JSON flow definitions; Zendesk executes them. You also don't have to build your own credential store, since ZIS Connections handles that.
Do most teams need ZIS? No. ZIS is a developer/ISV tool for custom integrations. Most teams are better served by a prebuilt Marketplace app, a simple webhook, or an AI/automation layer that connects to Zendesk for them. You reach for ZIS only when you're building a custom integration nothing prebuilt covers.
The bottom line
ZIS — Zendesk Integration Services — is Zendesk's serverless, hosted framework for building integrations: you describe the logic as event-triggered JSON flows, and Zendesk runs it on its own infrastructure, credentials and all, so you never stand up a backend. It's a genuinely useful tool, but a developer-facing one — and it lives alongside the API (call it from your code), webhooks (notify a system you host), the App Framework (UI inside the agent interface), and the Marketplace (install something prebuilt). Pick ZIS when you're building custom, event-driven integration logic and don't want to host the plumbing. If what you actually want is Zendesk doing more automatically — without a development project at all — an AI layer that connects for you is usually the faster road.
ZIS mechanics verified against Zendesk's official developer documentation, June 2026. Zendesk updates its developer platform periodically — confirm current limits, plan availability, and capabilities in the developer docs before relying on them.
