Your Zendesk token dies if nothing calls it for 30 days

The automation that breaks by not being used

Most things break when they run. This one breaks when it does not.

If you have a Zendesk automation that runs monthly, quarterly, at the end of a season, or only when somebody clicks it, the credential behind it now has a shelf life of thirty days. Nobody has to touch anything. The gap between two runs is the failure.

Zendesk has an entry for this in its own FAQ, and the question is worded almost exactly as an owner would ask it:

What if my integration runs infrequently (monthly/quarterly)?

If your token hasn't been used in 30 days, it will auto-deactivate starting July 28. The next time your workflow runs, it will fail with an authentication error.

• Announcing the removal of API tokens as an authentication method for API requests, Zendesk Help Center, published 1 June 2026, updated 2 September 2026

What exactly did Zendesk announce?

The whole change in the vendor's own words:

Zendesk is removing API tokens as an authentication method. Starting July 28, 2026, unused tokens will automatically deactivate. By April 30, 2027, all API tokens will stop working. You must migrate your integrations to OAuth before the final deadline. This change only affects APIs that currently use API tokens including the Ticketing, Help Center, and Voice APIs. It does not apply to other Zendesk products.

• same announcement

Read the last two sentences carefully, because the scope is narrower than the headline suggests and Zendesk repeats it elsewhere: "Only Support API tokens are affected. API tokens for Messaging, Chat, and other products are not part of this change."

That still covers the thing most small businesses actually automate. Tickets are the Ticketing API.

Which dates matter, and which have already passed?

Five dates, and by the time you read this three of them are behind you.

The dates come from the announcement's own calendar. The one worth noticing is the fourth: after 27 October the standard recovery move, issuing a replacement token, stops existing.

Every tutorial that has you call the Zendesk API by hand, from a script, from Postman, from a generic HTTP step, begins with "generate an API token in Admin Center". From that date, that instruction cannot be followed. If your token dies in November and you go looking for the button that makes a new one, it is gone.

The developer guide is also explicit that this is not only for accounts opened after the change:

Starting July 28, 2026, the 30-day inactivity rule applies to all accounts.

• Migrating from API tokens to OAuth, Zendesk developer documentation

And a revision of the announcement itself, dated 2 September, added a line for the other end of the account lifecycle:

New accounts blocked: Accounts created on and after July 28, 2026, cannot create or use API tokens.

• same announcement, "Phase 1", as revised on 2 September 2026

So a Zendesk account opened this summer never had the token page to begin with. If a tutorial written for an older account tells a new one to generate a token, the button it describes is not there, and the tutorial does not say why.

Can a dead token be brought back?

Yes, for sixty days, from a menu on the token's own row, and this is the part most summaries of the change get wrong.

You can reactivate any deactivated token within 60 days of when it was deactivated. After 60 days, the token is permanently deleted and cannot be recovered. After April 30, 2027, no tokens can be reactivated.

• same announcement, FAQ

The procedure is four steps, the last two being "Click the options menu icon next to the token and select 'Reactivate'. The token can immediately be used again."

The sentence "API tokens can no longer be reactivated" does appear in Zendesk's documentation, and it sits inside the row of a table describing 30 April 2027. It is a statement about the final deadline, not about today.

What does the failure actually look like?

The announcement never names an HTTP status. It says "will return authentication errors" and "will fail with an authentication error", which is not enough to diagnose anything. The migration guide does name 401, but only for OAuth, and never for a dead API token.

Tested against a live Zendesk instance with a token that does not work, the answer is a 401 with this body:

{"error":"Couldn't authenticate you"}

Now the part that matters. That is the same response you get when there is no authorisation on the request at all. It is the same response you get for a wrong email, a mistyped token, or forgetting the /token suffix that Zendesk's basic-auth format requires. There is no token_deactivated, no hint, no difference. A wrong subdomain is the one nearby mistake that does look different, because that one answers 404.

So the person debugging at 9am sees "Couldn't authenticate you", concludes that somebody rotated a password, and starts reissuing credentials. The actual fix was a Reactivate button on a page they were not looking at.

For contrast, an expired OAuth token answers usefully, and Zendesk documents the body:

When an access token has expired, Zendesk returns a 401 response with this body: { "error": "invalid_token", "error_description": "The access token provided is expired, revoked, malformed or invalid for other reasons." }

• Migrating from API tokens to OAuth, Zendesk developer documentation

Two more details for anyone who goes to the documentation to check. Zendesk's troubleshooting article for 401 lists "Expired or revoked API tokens" among the common causes and never uses the word "deactivated". And the API reference page that lists status codes covers the 400 range, 403, 409, 422, 429 and the 500 range, with no 401 in the list at all.

Zendesk's own advice is to guess

This is the most honest paragraph the vendor has published on the subject, and it is worth quoting in full because it tells you what the tooling cannot do:

How do I know which token caused a failed API request?

Currently, failed authentication requests don't show which specific token was used. If you're troubleshooting after a deactivation: Check the API tokens page for recently deactivated tokens. Reactivate all candidates (you have 60 days). Generate a usage report after your workflow runs to identify which token was used.

• same announcement, FAQ

Reactivate all candidates. That is the official procedure, and on an account with a dozen historical tokens it is not a small ask.

The report it mentions has its own catch. It covers "the previous seven days of API requests made with API tokens", and Zendesk suggests generating it repeatedly to "build a rolling 30-60 day history". The reporting window is seven days. The thing that kills the token is thirty days of silence. To have evidence that your quarterly job uses a particular token, you would have to start collecting it before anything goes wrong.

Who gets told?

Admins, in a digest, on a schedule:

Email notifications will alert all admins: 5 days before July 28 cleanup [...] Day 25 and day 29 before a token hits 30 days unused (deactivation warning) [...] All emails are batched daily and one email per day lists all affected tokens, not one email per token.

• same announcement

Everything about that is reasonable and none of it reaches the right person. The Zendesk admin role belongs to whoever runs support. The workflow lives in n8n, Make or Zapier, and was built by an agency, a contractor, a technical marketer, or by the owner two years ago. The token itself is deliberately not attached to a human: Zendesk's own help says each token "can be used by any verified user on the account and isn't associated with a specific user".

So a warning about a nameless credential arrives as one line in a daily digest to a role that does not own the automation. This is the same failure mode as a connection that expires while nobody is watching it, and the same reason somebody has to be actually watching the runs.

Where does your platform stand?

Not equally exposed, and the differences are larger than you would expect.

n8n is the most exposed, because the API token is the default. The authentication selector on both the Zendesk node and the Zendesk Trigger node lists API Token and OAuth2, and the node's source sets default: 'apiToken'. Whoever dragged the node in and filled the fields it asked for is on the method being retired.

Zapier warns, but names only one of the three dates. Its dedicated article, published on 3 September 2026, says this:

Zendesk is removing API token authentication for their Ticketing, Help Center, and Voice APIs. If you use Zendesk with Zapier on an older integration version (v1.x.x), you must update your Zaps to use the latest version with OAuth 2.0 before April 30, 2027, to avoid disruption.

• Action required - Update your Zendesk Zaps before the API token deprecation, Zapier Help Center, 3 September 2026

That is the only date in the article. The thirty-day rule is live now and it is not mentioned, nor is the October one. Zapier does give two clean tests for whether you are affected. That article says to check whether the connection "shows a version number (such as 1.x.x) with a 'Legacy' or 'Deprecated' tag". Its getting-started page for the integration puts it in terms of what you see on screen: if your connection "still asks for an Account, Agent Email, and API Token field, you are on an older integration version". It also warns that upgrading is not one button, because "available fields or output mappings may have changed between versions" and downstream steps need remapping.

Make is mostly out of the blast radius. Its Zendesk app has no API token field at all: the connection asks for a subdomain and then sends you to authorise in the browser. A Make release note from February 2026 names the mechanism, saying the connection type "supports the OAuth refresh token flow". Two caveats. Scenarios built on the generic HTTP or "Make an API Call" module with a hand-written Authorization header are on a token like anything else. And Make has published nothing about this deprecation, which makes sense if you have nothing to migrate, but means the notice will not arrive through the platform.

If you are the person who has to answer "which of our automations touch Zendesk and how do they authenticate", that inventory is worth doing before October rather than after a 401. It is also small enough to carry a price rather than an estimate.

Does moving to OAuth actually fix it?

Moving to OAuth solves the deprecation and can reproduce the original problem exactly, for the same automations.

Zendesk's guide gives the defaults: a refresh token lasts "30 days by default, configurable from 7 to 90 days", and clients created on or after 30 April 2026 get that default automatically. A quarterly workflow migrated onto the authorisation-code flow will therefore go quiet for ninety days, find its refresh token expired, and fail with a different message for the same underlying reason.

The two ways out are documented, in a different place from the problem. One is the client-credentials grant, which Zendesk describes as being "for server-to-server automation and background jobs where no user is available at runtime", and where there is no refresh token to expire at all. The other is to raise refresh_token_expires_in towards ninety days. Neither is connected to the infrequent-automation case the same FAQ describes. One caveat on the first, from the guide itself: actions taken with a client-credentials token are attributed to whoever created the OAuth client, usually an admin, so create a service account to own it if attribution matters.

There is a second date on the OAuth side that is easy to miss, because it lives in a separate announcement from February. Local OAuth clients created from 30 April 2026 get expiring tokens automatically; for the ones created earlier, the deadline "for existing local (non-global) OAuth clients to adopt the refresh token flow has been extended to April 1, 2027". An integration that moved to OAuth a year or two ago, took a token once and has been reusing it since, is not finished migrating. It has a month less than the token deadline, and it will fail with an OAuth error rather than an authentication-method one.

There is one class of integration with no native path yet. On webhooks that call back into your own Zendesk account, the announcement says using API tokens "is no longer supported and will stop working as part of this EOL", followed by a promise that native OAuth support for webhooks is coming "ahead of the April 2027 deadline" with "a specific timeline [...] shared when available". No timeline had appeared by early September.

Is anyone actually stuck on this?

Not yet in the way you would expect, and it is worth being honest about that. As this was written, the public discussion was people reading the announcement and preparing rather than people picking up the pieces, which fits the calendar: the first permanent deletions were not due until 26 September.

What the discussion does show is who this lands on. A Zendesk admin describing themselves, in the vendor's own community:

I am Admin for our ZD instance, and I work on the business side, not IT. [...] I have no idea how to transition to OAuth for my needs. There is not documentation that provides me any guidance. I have no experience with OAuth, and this looks like something I'll need IT assistance to set up - but I have no idea what to even ask for.

• a user, Removal of API tokens - how do I use OAuth for Postman and Power Automate, Zendesk community, 16 June 2026

A Zendesk employee replied that they were not familiar with the tool in question and recommended "reaching out to someone familiar with that service". The answer that actually worked arrived a week later from another community member, and the original poster confirmed in August that it worked. A Community Expert put the general point plainly in the same thread: "Zendesk should update their documentation and provide assistance during this period."

A second thread is more uncomfortable, because it is about an officially documented integration. A customer provisioning Zendesk users from Microsoft Entra ID reported that the official connector "only supports Admin Username + Secret Token" with "no OAuth option on the Microsoft side". Their conclusion: "on 2027-04-30, this officially documented integration will stop working for every customer using it - and there is nothing customers can do about it on their own". Zendesk's answer was that Microsoft maintains the connector and has plans to update it.

Waiting for a platform to fix this for you is not a plan on the n8n side either. Somebody submitted a working, tested pull request on 3 September to let the Zendesk credential use the grant types this situation calls for. A bot closed the linked issue thirteen seconds after it was opened, then closed the pull request because the issue was "resolved". The author asked for it to be reopened the same hour, and the pull request was still closed and untouched four days after that.

What to do this month

1. Open Admin Center and look at the API tokens page. It now has a "Deactivates on" column showing when each unused token will go. Nothing else in this change tells you as much for as little effort.
2. Reactivate anything you recognise, today. July's deactivated tokens started being deleted permanently on 26 September, and after deletion there is no button.
3. List every automation that touches Zendesk, including the ones that run monthly, quarterly or never. Those are the ones at risk, precisely because they are the ones nobody thinks about.
4. Check what each one authenticates with. In n8n, open the node and look at the Authentication selector, because the default is the retired method. In Zapier, look for Account, Agent Email and API Token fields. In Make, check any custom HTTP calls.
5. Migrate before 27 October rather than before April 2027. After October you cannot issue a replacement token, which removes the fallback that makes an unhurried migration feel safe.
6. If the workflow is infrequent, pick the grant type deliberately. Otherwise you will move it to OAuth and rediscover the same failure in ninety days.
7. Do not assume the warning email will reach you. It goes to admins, batched, listing token IDs.

When this is a job to hand over

Reconnecting one Zapier step takes about twenty minutes, and there is no reason to pay anyone for it.

It becomes a job under four conditions, and most people meet at least two of them. Nobody can list which automations touch Zendesk. The integration is a hand-rolled script somebody built and left. The workflow runs rarely enough that a wrong migration stays invisible until next quarter. Or the run is already broken, the 401 says nothing, and the token page is a list of names that mean nothing.

None of that is open-ended work. It is an inventory, a migration per integration, and a decision about grant types made once. We quote it as a Fix off that inventory, and the integration work we take tends to arrive looking exactly like this.

Worth writing on a note somewhere before you close the tab. The thing holding your automation together is now perishable, the warning about it goes to a role rather than to a person, and when it dies the message you get looks exactly like a typo in a password.

Sources

• Announcing the removal of API tokens as an authentication method for API requests - Zendesk Help Center, published 1 June 2026, revised 2 September 2026, read 7 and 12 September 2026. The three phases and their dates, the block on token creation for accounts opened from 28 July, the scope limited to Support API tokens, the 60-day reactivation window and the one-click procedure, the full key-date calendar, the FAQ answers on infrequent integrations and on identifying which token failed, the email notification schedule and batching, and the webhook statement with no timeline.
• Announcing the required expiration of global OAuth access and refresh tokens - Zendesk Help Center, published 2 February 2026, read 12 September 2026. The 1 April 2027 deadline for existing local OAuth clients to adopt the refresh token flow, and the default token lifetimes applied to local clients created from 30 April 2026.
• Migrating from API tokens to OAuth - Zendesk developer documentation, read 7 September 2026. The 30-day inactivity rule applying to all accounts from 28 July, the documented body of an expired OAuth token response, the two grant types, and the refresh token lifetime defaults and range.
• Managing API token access to the Zendesk API - Zendesk Help Center, updated 21 July 2026, read 7 September 2026. Tokens not being associated with a specific user, and calls beginning to fail as soon as a token is deactivated.
• Troubleshooting 401 and 403 Errors on the Zendesk Developer Platform - Zendesk Help Center, updated 21 July 2026, read 7 September 2026. The listed causes of a 401, which include expired or revoked API tokens and do not use the word deactivated.
• Action required - Update your Zendesk Zaps before the API token deprecation - Zapier Help Center, published 3 September 2026, read 7 September 2026. The April 2027 deadline as the only date named, the legacy version-tag test, and the warning that fields and mappings may change between integration versions.
• How to get started with Zendesk on Zapier - Zapier Help Center, updated 3 September 2026, read 7 September 2026. The current connection flow through a browser authorisation, and the test by which an older connection is recognised from the Account, Agent Email and API Token fields it asks for.
• Zendesk app documentation - Make apps documentation, read 7 September 2026. The connection form asking only for a subdomain followed by browser authorisation, with no API token field.
• New MMS options and app updates - Make Help Center, February 2026, read 7 September 2026. The Zendesk connection type supporting the OAuth refresh token flow.
• n8n-io/n8n - n8n source, read 7 September 2026. The authentication options on the Zendesk node and Zendesk Trigger node, with API Token as the default value.
• Removal of API tokens - how do I use OAuth for Postman and Power Automate - Zendesk community, June to August 2026, read 7 September 2026. An admin describing the migration from the business side, the employee reply, the Community Expert's comment on documentation, and the eventual resolution by another community member.
• API token EOL (April 2027) - Integration path have no OAuth migration option - Zendesk community, July 2026, read 7 September 2026. The Microsoft Entra provisioning connector supporting only token authentication, and Zendesk's reply that Microsoft maintains it.
• feat(Zendesk Node) - Add support for PKCE and client credentials grant types - n8n on GitHub, 3 September 2026, read 7 September 2026. The pull request closed by a bot after its linked issue was closed as a feature request, and the author's request to reopen it.