← Back to Blog
Zendesk API Tokens After 27 October 2026: What Changes and How to Move to OAuth
·5 min read
On 27 October 2026, Zendesk stops every account from creating a new API token. That is the whole change on that date. Tokens you already have do not stop working on 27 October: Zendesk says existing active tokens "remain usable until April 30, 2027 unless deactivated". On 30 April 2027, every remaining token is deactivated for good.
So 27 October is not a cut-off for your integrations. It is the day you lose the ability to replace a token, and that is what makes it worth planning for now. This guide covers what changes, what quietly breaks, and how to move each integration to OAuth, the method Zendesk is replacing API tokens with.
The three dates, kept separate
Zendesk is retiring API tokens in three phases. They are easy to blur together, so here they are as Zendesk states them in its announcement and its migration guide:
| Date | What happens |
|---|---|
| 28 July 2026 (already in effect) | Any token unused for 30 days is deactivated, and this keeps happening from then on. Tokens left deactivated for 60 days are deleted permanently. Accounts created on or after this date cannot create or use API tokens at all. |
| 27 October 2026 | No account can create a new API token, through the UI or the API. Existing active tokens keep working. |
| 30 April 2027 | All remaining API tokens are deactivated permanently. Admins cannot reactivate them. |
Zendesk also confirms the two methods run side by side in the meantime: "OAuth access tokens and API tokens both work until April 30, 2027. You can migrate integrations one at a time."
What 27 October actually breaks
Nothing that is running today stops on 27 October. What stops is anything that creates a token:
- Setup runbooks. Any internal guide whose first step is "generate an API token in Admin Center" no longer works for a new integration.
- Rotation scripts. A security process that issues a fresh token and retires the old one will fail at the "issue" step.
- Re-connecting a tool. If a vendor's connector asks you to paste in a Zendesk API token, you will not be able to make one.
The quieter risk is the 30-day rule that has applied since 28 July. An integration that runs rarely, such as a monthly export or a quarterly sync, can sit unused long enough for its token to be deactivated, and deleted 60 days after that. Before 27 October you could simply create a new token. After it, you cannot. The job that worked last quarter will fail the next time it runs, and the only fix is the OAuth migration you were going to do anyway, now done under pressure.
How to move an integration to OAuth
Zendesk's migration guide sets out the path. In short:
- Create an OAuth client in Admin Center, under Apps and integrations › APIs › OAuth clients.
- Pick a grant type. Use the authorization code flow when a person approves the access, and client credentials for server-to-server automation such as syncs and scripts.
- Get your tokens. Exchange the authorization code, or request a token with your client credentials.
- Handle expiry. OAuth access tokens are short-lived. Zendesk's defaults are 30 minutes for access tokens (configurable from 5 minutes to 48 hours) and 30 days for refresh tokens (configurable from 7 to 90 days). With the authorization code flow, exchange the refresh token for a new pair automatically. With client credentials, request a new token when the old one expires.
- Switch your requests to Bearer authentication instead of the email-and-token credentials you use today.
The expiry step is where most of the work is. An API token used to stay valid indefinitely, so many integrations store one in a config file and never think about it again. An OAuth integration has to fetch, store and renew tokens, and recover cleanly when one has expired.
A checklist for the next three weeks
- Inventory every integration that authenticates to Zendesk: middleware, internal scripts, data-warehouse syncs, reporting tools, anything a contractor built.
- Find anything that creates tokens (runbooks, onboarding docs, rotation jobs) and rewrite it for OAuth before 27 October.
- Look for low-frequency jobs. Monthly and quarterly tasks are the ones the 30-day rule catches. Migrate those first, or confirm they have run recently.
- Migrate one integration at a time. Both methods work until 30 April 2027, so there is no need for a single cut-over day. Move one, watch it through a few token refreshes, then move the next.
- Put 30 April 2027 in the calendar as the date the last token stops, and plan to finish well before it.
For the full list of Zendesk's migration dates through 2028, including the Chat retirement, see our Zendesk migration calendar.
If you are choosing a helpdesk API now
DeskLeap's REST API uses keys you create in your workspace settings, and you can revoke any key at any time. You can see what connects to DeskLeap on our integrations page.