Zendesk API Token Deprecation: OAuth Migration Guide

zendesk, oauth, api, vendor-evaluation

Zendesk is retiring the plain API token as a way to call its Ticketing, Help Center, and Voice APIs, replacing it with OAuth. The change lands in three dated phases: tokens unused for 30+ days start getting deactivated from July 28, 2026; creating a new API token stops working entirely on October 27, 2026; and every remaining token is deactivated for good on April 30, 2027, with the token-management pages then removed from Admin Center. There is no opt-out and no extension. If any of your integrations authenticate with a token pasted into a header, one of these three dates is already on your calendar whether you've scheduled it or not.

What actually changes, and when

The mechanics matter as much as the dates. An API token authenticates as HTTP Basic auth — email and token, base64-encoded, decoded on every request — with no scope restriction: it can reach any endpoint the authenticating user is allowed to use. An OAuth access token is sent as a Bearer token, can be scoped to only the endpoints an integration actually needs, and — for OAuth clients created after April 30, 2026 — expires automatically, 30 minutes by default, instead of staying valid indefinitely until someone remembers to revoke it. Migrating isn't a drop-in credential swap. It's a chance to shrink what each integration can do if it leaks, which a bare token never offered.

What breaks first: the token nobody remembers issuing

Phase one is the one teams miss, because on July 28, 2026 nothing you're actively using breaks — it targets unused tokens specifically. That's exactly the shape of the token nobody remembers: a one-off script from two years ago, a proof-of-concept that got shelved, a former teammate's personal token still sitting active. If you haven't audited your token list before that date, phase one audits it for you, silently, and it does not distinguish "abandoned" from "used once a quarter and about to be needed again."

The known gap: Microsoft Entra's provisioning connector

Not every integration has an OAuth path ready yet. In a Zendesk community thread, an admin who provisions users into Zendesk through Microsoft's Entra ID connector reported that the integration has no OAuth migration option. The connector is maintained by Microsoft, not Zendesk, and Zendesk's own reply pointed the poster to Microsoft — noting Microsoft has plans to update the connector ahead of the EOL, without committing to a date. If provisioning, SSO, or any other third-party connector into Zendesk runs through a vendor that isn't Zendesk itself, check that vendor's migration status directly. Zendesk's own OAuth documentation only covers integrations you control the code for.

Six-point checklist before April 30, 2027

1. List every live token. Admin Center → Apps and integrations → APIs → API tokens. Name each one after the system it's pasted into — a token with no known destination is the one likeliest to break without anyone noticing.
2. Check last-used activity, not just existence. The audit log next to each token (Enterprise plans) records when it was created, deactivated, and reactivated — anything idle is already inside the July 28 sweep window.
3. Confirm third-party connectors have a published OAuth path, not just the scripts you wrote yourself. Ask the vendor directly if their docs don't say — see Microsoft Entra above for what "no answer yet" looks like from the inside.
4. Scope the new OAuth client narrower than the token it replaces. An API token carries the full permission set of whoever issued it; an OAuth client doesn't have to.
5. Migrate one integration at a time. OAuth access tokens and API tokens work side by side until April 30, 2027 — no reason to cut everything over on the same day, and no reason to wait for the last one either.
6. Put October 27, 2026 on its own calendar entry. After that date you can't mint a new token as a stopgap for a migration that slipped — only reissue or rotate ones that already exist, until phase one or three sweeps them up.

Since you're already in the authentication code

Rewriting how a dozen integrations authenticate isn't a small change, and Zendesk didn't give you a choice about timing it. That combination — mandatory, touching code you'd otherwise leave alone for years — is also the cheapest moment to ask whether the platform underneath is worth another five years of migrations like this one. Not "switch platforms because a vendor deprecated something" — every vendor eventually deprecates something. If this migration has you evaluating the vendor relationship more broadly, the fifteen questions worth putting to any vendor's documentation before shortlisting a replacement apply here too. And if part of what's authenticating is tool-calling rather than a plain REST integration, what three support platforms actually shipped on that front is worth fifteen minutes if you haven't looked.

Where Replium stands on this

Applying the same standard to ourselves: the credential a teammate pastes into an MCP client is also a static bearer token, hashed and stored the same way — no OAuth flow, no scoping to specific endpoints. If we ever had to run the migration Zendesk is running, we'd owe our users the same kind of notice.

What's different for now: the token dies the moment the person who issued it stops being a teammate, with no separate revocation step for anyone to forget, and it isn't something we've deprecated or have plans to. We also don't carry Zendesk's twenty-year surface of legacy integrations — there's one endpoint, MCP, and its tokens are a few months old as a feature, not several years.

Who this isn't for: if you're deep in Zendesk's ecosystem — Voice, an Entra-provisioned workforce, a decade of custom apps — nothing above changes that; migrate your tokens, this isn't a switching argument. It's for anyone touching integration auth this quarter who wants to know what else is on the table while the code is already open. If that's you, Replium is self-serve to try — an email, a confirmation link, no card, and no migration deadline of our own making yet.