Zendesk Ending Incremental APIs for Third Parties: Migration Guide

Starting December 2, 2026, Zendesk will block third-party developers from using its Incremental Export APIs — the endpoints that power virtually every bulk data sync, ETL pipeline, and migration tool connected to Zendesk. If you're planning a Zendesk migration or rely on a third-party integration that syncs ticket, user, or chat data in bulk, this change will break things unless you act before enforcement completes on January 19, 2027.

For engineering teams and IT administrators, the mandate is straightforward: automated migration tools and third-party apps relying on incremental bulk exports will fail unless they are re-engineered to use standard list endpoints or authorized via first-party credentials.

This article covers exactly what's changing, who's affected, the alternative endpoints available, and the technical trade-offs each path introduces.

What Is Zendesk's Incremental API Deprecation?

Zendesk's Incremental API deprecation is the removal of third-party access to all /api/v2/incremental/* endpoints — the bulk export APIs that return every record created or modified since a given Unix timestamp. Zendesk announced this change on September 22, 2026, with enforcement rolling out between December 2, 2026 and January 19, 2027.

The Incremental Exports API lets you fetch records changed since a specific point in time by passing a start_time parameter. This makes it the backbone of efficient ETL and migration workflows — an external system can ask Zendesk for a clean, time-ordered batch of every ticket, user, or organization that changed since the last sync. Without it, third-party tools must fall back to standard list endpoints, a fundamentally different extraction pattern with real performance and reliability consequences.

Who Is Affected — and Who Isn't?

This is the single most important distinction, and it's easy to miss:

• Zendesk customers using internal/first-party integrations: Not affected. You can continue using Incremental APIs for your own internal use cases. If you're writing a custom script using your own admin credentials to pull your own data, you retain full access. No action required.
• Third-party apps and integrations: Affected. Any tool, connector, or integration that authenticates as a third-party developer — including ETL platforms like Fivetran, Airbyte, and Stitch; migration services; Marketplace apps; and custom integrations built by external contractors — will lose access to incremental endpoints.

The distinction hinges on how the integration authenticates, not what it does. A custom Python script running under your own Zendesk account's credentials is first-party. A Marketplace app using OAuth client credentials scoped to your instance is third-party.

Key Dates and the Extension Window

Zendesk will pause the rollout over the holiday period. Account admins can request a 60-day extension for specific partners starting November 2026 through Admin Center → Apps & integrations → APIs → API Configuration. Select the partner from the drop-down and save. This buys time — but only 60 days.

Why Is Zendesk Removing Incremental API Access for Third Parties?

Zendesk's stated reason is security. Incremental APIs are designed for bulk data transfer — they return every record in a timeframe, which makes them efficient for syncs but creates a massive vulnerability if a third-party application's credentials are compromised. A single API call to the incremental endpoint can exfiltrate thousands of tickets, user records, or chat transcripts in minutes.

By forcing third-party applications onto transactional and search APIs, Zendesk achieves two security objectives:

1. Minimizes exposure: Transactional APIs force targeted requests for specific records or constrained lists, rather than open-ended full-timeframe datasets.
2. Limits breach impact: Without incremental endpoints, rapid bulk exfiltration is technically impossible. Any unauthorized extraction becomes slower and smaller-scale, increasing the likelihood of detection by rate-limiting and anomaly-monitoring systems.

This isn't theoretical. As AI workflows scale and more integrations handle sensitive data, the attack surface of bulk export APIs becomes a real liability for any platform vendor.

Which Endpoints Are Going Away — and What Replaces Them?

Zendesk published a complete remap table. Here are the endpoints that matter most for migrations and data syncs — for the full engineering treatment of each, see our endpoint-by-endpoint playbook:

Zendesk Talk: No Alternative Exists

The most painful gap is Zendesk Talk. The incremental call and call-leg export endpoints (/api/v2/channels/voice/stats/incremental/calls and /legs) have no designated replacement. Zendesk has stated this explicitly.

If your migration or analytics pipeline depends on bulk call data, you must extract and archive this data before enforcement kicks in using first-party credentials. Non-incremental Talk stats endpoints exist but are not designed for bulk export.

What Breaks When You Switch to Standard Endpoints

Switching from incremental to standard list endpoints isn't a URL swap. There are real behavioral differences that affect data pipelines:

No Native "Changed Since" Filter

The Incremental API's core feature is the start_time parameter: give it a Unix timestamp, and it returns everything created or modified after that moment. Standard list endpoints like /api/v2/tickets/ don't have this. You can sort by updated_at with cursor pagination, but you lose the guarantee that you're getting only changed records. Your sync logic must handle deduplication and reconciliation on the client side.

Replication Keys Change

The singer-io tap-zendesk project already documented this: the tickets stream's replication key changes from generated_timestamp (set by the incremental API) to updated_at (the only field available on the standard endpoint). If your pipeline logic relies on generated_timestamp for bookmarking, it breaks.

Rate Limit Math Gets Worse

Incremental Export endpoints have a dedicated rate limit of 10 requests per minute (30 with the High Volume API add-on), separate from the general API limit. Standard list endpoints share the account-wide rate limit bucket: 200 req/min on Team plans, 400 on Growth/Professional, and 700 on Enterprise. On a Team plan, your migration competes with every other integration, webhook, and UI-triggered API call on your account.

A migration that previously took 1,000 API calls via incremental endpoints might require 15,000+ calls via standard endpoints, rapidly exhausting those shared rate limits.

Offset Pagination Ceiling

Zendesk enforces a hard limit: offset-based pagination past 10,000 records returns a 400 Bad Request. Cursor-based pagination has no such limit, but you must explicitly opt in with the page [size] parameter. Any extraction code still using offset pagination will fail on datasets larger than 10,000 records.

Cursor Expiration and State Management

Transactional endpoints rely on cursor-based pagination, and cursors expire. A migration script cannot simply pause for an hour and resume using the same state marker. State management must become highly resilient — persist cursor state, handle expired cursors gracefully, and implement retry logic.

Ticket Metric Events Are Now Sideloaded

The incremental ticket_metric_events endpoint returned metric events as a standalone stream. The replacement (/api/v2/tickets?include=metric_events) sideloads them onto ticket responses. Metric events are no longer independently queryable — they come attached to ticket payloads, which means you parse them differently and may need to restructure your downstream tables.

This Lands Alongside API Token Retirement

Zendesk is also retiring API tokens as an authentication method. The timeline overlaps:

• October 27, 2026: New API token creation blocked
• April 30, 2027: All remaining API tokens permanently deactivated

If your extraction scripts authenticate with an API token and use incremental endpoints, you're dealing with two breaking changes at once. OAuth is the required forward path. Plan the authentication migration alongside the endpoint migration — doing them separately doubles your testing and deployment effort.

Three Paths to Keep Your Zendesk Data Extraction Working

There's no single right answer. The right path depends on who's running the extraction and on what timeline.

Path 1: Run Under First-Party Access (Recommended)

If you or your migration partner run extraction scripts under the customer's own Zendesk account credentials (not as a third-party OAuth app), incremental endpoints remain fully available. This is the simplest path — it avoids the endpoint migration entirely.

By providing your migration engineers with a first-party API token (or OAuth credentials scoped to your own account), the extraction script operates as an internal tool. This retains full access to the high-volume Incremental APIs, keeping the migration fast and reliable.

When it works: One-time migrations, internal data syncs, or cases where the customer can grant first-party credentials directly.

When it doesn't: Ongoing third-party SaaS integrations, Marketplace apps, or situations where the vendor can't or won't accept first-party credentials.

Path 2: Request the 60-Day Extension

Starting November 2026, account admins can grant specific partners a 60-day extension via Admin Center. This doesn't solve the problem — it delays it. Use this to buy time while you re-engineer extraction or finalize a cutover that spans the enforcement window. Not a permanent plan.

Path 3: Re-Engineer Onto Standard Endpoints

This is the permanent fix for third-party integrations. It means:

• Replacing incremental endpoints with cursor-paginated list endpoints (/api/v2/tickets/, /api/v2/users/, etc.)
• Implementing client-side change detection (compare updated_at against your last sync bookmark)
• Building deduplication and reconciliation logic
• Handling rate limits against the shared account-wide bucket
• Restructuring any pipeline that consumed ticket_metric_events or ticket_events as independent streams

# Cursor-paginated ticket extraction with change detection and rate-limit handling
import requests
import time
 
def extract_tickets_since(subdomain, oauth_token, last_updated_at):
    url = f"https://{subdomain}.zendesk.com/api/v2/tickets.json"
    headers = {"Authorization": f"Bearer {oauth_token}"}
    params = {
        "page[size]": 100,
        "sort": "updated_at",
    }
    all_tickets = []
 
    while url:
        resp = requests.get(url, headers=headers, params=params)
        if resp.status_code == 429:
            retry_after = int(resp.headers.get("Retry-After", 60))
            print(f"Rate limit hit. Sleeping for {retry_after} seconds.")
            time.sleep(retry_after)
            continue
        resp.raise_for_status()
        data = resp.json()
 
        for ticket in data.get("tickets", []):
            if ticket["updated_at"] <= last_updated_at:
                return all_tickets  # Reached already-synced records
            all_tickets.append(ticket)
 
        url = data.get("links", {}).get("next")
        params = {}  # Params are encoded in the next URL
 
    return all_tickets

This works, but it's significantly more code, more edge cases, and more surface area to test than the incremental endpoint ever required.

How ETL Platforms and Connectors Are Responding

The open-source ecosystem is already adapting. The singer-io/tap-zendesk project has a pull request migrating five affected streams to cursor-paginated replacement endpoints. Estuary's connectors team has opened a research issue to assess impact across their Zendesk source connectors.

Key questions these teams are working through — and that you should ask your ETL vendor:

• Will the sync strategy change from incremental to full refresh?
• Will primary keys or document shapes change?
• Is Talk data (calls, legs) still extractable at all?
• What happens to in-progress syncs when enforcement kicks in mid-rollout?

If your vendor hasn't communicated a plan for this change, that's a red flag. Ask now.

How ClonePartner Handles This

No third-party developer is exempt from this change. But because ClonePartner writes custom extraction scripts for each migration rather than relying on fixed connector templates, we adapt when API surfaces shift. Here's our approach for Zendesk migrations:

1. First-party credential path: Where possible, we run extraction under the customer's own internal access, which retains full incremental API availability. This is the fastest, cleanest option for one-time migrations.
2. 60-day extension bridge: For migrations that span the enforcement window, we coordinate the partner extension request through Admin Center to maintain incremental access through the project.
3. Re-engineered extraction on standard endpoints: For long-running integrations or cases where first-party access isn't available, we build extraction on the supported endpoints with cursor pagination, rate-limit handling, and client-side dedup/reconciliation baked in.

We've shipped through API changes like this before without downtime. The difference between a tool that breaks silently and a team that adapts in real time is exactly what this kind of deprecation exposes.

What You Should Do This Week

1. Audit your integrations. List every third-party app and integration that connects to Zendesk. Check whether any use incremental endpoints — your vendor should be able to tell you.
2. Check your Talk dependency. If you have Zendesk Talk data in your pipeline, flag it immediately. There is no replacement endpoint for incremental call/leg exports.
3. Ask your ETL vendor for their plan. If they don't have one published yet, push for a timeline.
4. Decide your auth path. With API tokens being retired by April 2027, plan the OAuth migration at the same time. Don't do these separately.
5. Test the replacement endpoints now. Don't wait until December. The standard list endpoints behave differently — response shapes, pagination, rate limits — and your pipeline code needs to handle those differences.