How to Fix Zendesk Zaps Before the API Token Deprecation: Migrate to OAuth 2.0

Introduction

If your support automations still run on an old Zendesk connection in Zapier, they have a fixed expiry date. Zendesk is removing API token authentication for its Ticketing, Help Center, and Voice APIs, and Zapier Zaps built on the legacy Zendesk integration version will stop authenticating when the last tokens die. This tutorial walks you through the full fix: finding every affected Zap, adding an OAuth 2.0 connection, upgrading each Zap step by step, and proving the result with a test ticket.

Quick answer

Find every Zap on the legacy Zendesk version in Zapier, reconnect it with OAuth 2.0, remap any changed fields, test the step, and publish the Zap before April 30, 2027.

Evidence

The deadline is not a rumor or a forum guess. It comes from two first party sources that agree on the same date. Zapier’s own migration notice states the requirement plainly: “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.” That sentence is the whole project in one line, and it tells you the two things that matter: the trigger is the integration version, not the age of your account, and the fix is a version upgrade, not a new token.

Zendesk’s phased timeline, published in its developer changelog, fills in the dates before the final cutoff. Starting July 28, 2026, Zendesk began deactivating API tokens unused for 30 days or more, and tokens left deactivated for 60 days are permanently deleted. Starting October 27, 2026, accounts can no longer create new API tokens through the UI or the API. On April 30, 2027, all remaining API tokens are permanently deactivated, admins can no longer reactivate them, and the API token management pages leave Admin Center. As of this article’s publication date, October 25, 2026, you are two days away from the new token cutoff and about six months from the final cutoff, which is comfortable for a careful migration and far too short to ignore.

Two more numbers shape the plan. First, the migration is per Zap, not per account, so a team with twenty Zendesk Zaps has twenty upgrades to perform and test. Second, Zendesk’s guide to managing API token access notes that an account can hold up to 256 API tokens, which is why large teams often discover forgotten tokens only when something breaks. An inventory first, then a migration, is the only order that works.

Prerequisites

Before you start, gather these items:

• Administrator permissions in your Zendesk account, or an admin willing to authorize the new connection with you. Zapier’s Zendesk getting started guide lists administrator permissions as a requirement, along with a Zendesk Team plan or higher.
• A paid Zapier plan, because Zendesk is a premium app on Zapier and is not available on the free plan.
• Your Zendesk subdomain, which is the part before .zendesk.com in your help center address. Double check the spelling now, because a wrong subdomain is the most common cause of a failed connection attempt.
• A list of your Zendesk Zaps, or at least access to Zapier’s My Apps page so you can build that list in step 1.
• A test ticket you can create safely, so you can prove each migrated Zap still works before you rely on it.
• A maintenance window in which a brief pause per Zap is acceptable. Upgrading a Zap means editing it, and you should not edit a Zap in the middle of a ticket surge if you can avoid it.

Step-by-step guide

Step 1: Audit your connections and list every affected Zap

Log into Zapier and open My Apps. Search for Zendesk and select it to review your Zendesk connections. Look for a version number such as 1.x.x with a Legacy or Deprecated tag. That tag is the signal: any Zap using that connection must be updated. A connection with no version tag is likely already on the current OAuth based version, and Zaps using it need no action.

Now build the actual work list. Open each Zap that uses the legacy connection and write down its name, its trigger, and what it does with the ticket. Do not trust your memory here. Teams routinely find Zaps they forgot about, including one off automations built for a campaign or a former colleague’s onboarding flow, and an unlisted Zap is an unmigrated Zap. Keep this list open for the whole migration and check items off only after the Zap is republished and tested.

Step 2: Add a new OAuth connection without touching the old one

Go back to My Apps, click Add connection, search for Zendesk, and add a new connection. Zapier opens a Connect an Account page where you enter your Zendesk subdomain and continue. A Zendesk login and authorization page then opens. Log in if prompted and grant Zapier permission to access your account. The new connection uses OAuth, so it does not ask for an agent email and an API token the way the legacy connection did.

Do not delete the old connection yet. Your legacy Zaps still point at it, and deleting it before the migration would break them immediately instead of on the deprecation date. The old connection stays until every Zap on it has been upgraded and observed working, and only then do you remove it, as described in step 5.

Step 3: Upgrade one Zap at a time in the Zap editor

Work through your list one Zap at a time, starting with the least critical Zap so any surprise is cheap. Open the Zap in the editor and click the affected Zendesk step. In the Setup tab, click Change to update to the newest Zendesk integration version. In the Account dropdown, select the new OAuth connection you created in step 2, or select Connect a new account if you have not created it yet, in which case Zapier redirects you to Zendesk to authorize it.

Next, review and reconfigure the step’s fields in the Setup tab. Available fields or output mappings may have changed between versions, so do not assume a one to one carryover. If a field you relied on is gone or renamed, pick the closest current field and note the change in your migration list. Then remap the fields in all downstream steps, meaning every later Zap step that used this step’s output. This is the step most people skip, and it is the most common cause of a Zap that tests fine in isolation but writes garbage, or nothing, in production.

Click Test step to pull in the latest data and confirm the step still returns what you expect. If the test returns a real ticket with the fields you need, you are ready to publish. Click Publish to save your changes and turn the Zap back on. Repeat this process for each Zap on your list. There is no bulk upgrade, and that is by design: each Zap’s field mapping is its own, so each one deserves its own test.

Step 4: Prove the migration with a real ticket and Zap history

A green test step is necessary but not sufficient. Create a test ticket that matches the Zap’s trigger, or trigger the action the Zap performs, and watch it flow end to end. Then open the Zap’s history in Zapier and confirm the run succeeded with the expected output. Check the ticket in Zendesk as well, because a Zap can report success while writing to the wrong field, and only the ticket itself shows that.

Let the migrated Zaps run normally for at least one business day before you call the migration done. Some triggers only fire on specific ticket events, such as a status change or a new comment, and a Zap that looks fine on a create test can still fail on an update path. If a Zap has multiple triggers or paths, exercise each one you care about. Keep the old connection in place during this observation period so you can compare behavior and roll a single Zap back if a field mapping turns out to be wrong.

Step 5: Remove the legacy connection and record the change

Once every Zap on your list is upgraded, tested, and observed, remove the legacy connection from My Apps. This is the step that turns a migration into a guarantee: with no legacy connection left, no Zap can quietly fall back to token authentication. If a Zap still references the old connection at this point, Zapier will show it, and that Zap goes back to step 3 instead of being deleted.

Finally, write down what changed. Record the date, the new connection name, and the list of migrated Zaps, and share it with anyone who manages support automations. Future you, or a future teammate, will otherwise have no way to tell whether a Zendesk connection is the OAuth one or a leftover, and the next authentication change will start with the same audit you just did.

Troubleshooting

The Zap still shows the legacy version after I added a new connection

Adding a connection in My Apps does not upgrade any Zap. The version lives on each Zap’s Zendesk step, not on the account level. Open the Zap in the editor, click the Zendesk step, use Change in the Setup tab to move to the newest version, select the new connection, remap downstream fields, test, and publish. Repeat for every Zap, because each one must be upgraded individually.

The test step returns 401 Unauthorized

A 401 after the deprecation timeline started usually means the credential behind the step is a deactivated or deleted API token, not a typo. Tokens unused for 30 days were deactivated starting July 28, 2026, and tokens left deactivated for 60 days were permanently deleted, so a dormant Zap’s token may already be gone even though the Zap itself looks unchanged. Do not try to fix this by creating a fresh API token, since new token creation stops on October 27, 2026 and all tokens die on April 30, 2027. Switch the step to the new OAuth connection and test again.

Fields or outputs are missing after the upgrade

The field set and output data can change between integration versions, so a field your old Zap used may be renamed, moved, or removed. Open the upgraded step’s Setup tab and compare its fields with your migration notes. Remap every downstream step that consumed the old output, then test with a real ticket, not just the sample data, because sample data can hide a mapping that only breaks on a specific ticket type. If a field truly has no equivalent, restructure that part of the Zap around the closest current field before you publish.

The new connection authorization fails

First, recheck the subdomain: it must match your Zendesk address exactly, without extra dots or a trailing slash. Second, confirm you are authorizing with an account that has administrator permissions in Zendesk and that the account is on a Team plan or higher, since both are listed as prerequisites for the Zapier Zendesk app. Third, if you see an error about an existing connection, check whether you are accidentally reauthorizing the legacy connection instead of creating a new one, and start the Add connection flow from My Apps rather than from inside an old Zap step.

A migrated Zap publishes but never runs

Confirm the Zap is actually on after publishing, then check its history for runs and for any error entries. A common cause is a trigger filter that the test ticket did not match, for example a specific ticket status, group, or tag. Create a test ticket that satisfies the trigger exactly, and check the Zendesk side to confirm the event happened. If the Zap uses a polling trigger, allow a full polling interval before concluding it is broken, and compare against the Zap’s previous run pattern in its history.

FAQ

What happens to my Zendesk Zaps if I do nothing before April 30, 2027?

Zaps on the legacy Zendesk integration version stop authenticating, because Zendesk permanently deactivates all remaining API tokens on that date. The Zaps fail with authentication errors instead of creating or updating tickets, so the fix is to move each affected Zap to the OAuth 2.0 version before the deadline.

Can I just create a new Zendesk API token instead of migrating to OAuth?

No, a new API token is not a fix. Zendesk blocks new API token creation from October 27, 2026, and every remaining token stops working on April 30, 2027. A token created before the cutoff only postpones the same failure by a few months, while an OAuth connection keeps working past the deadline.

Do I have to update every Zendesk Zap individually?

Yes. Adding a new OAuth connection in Zapier does not upgrade the Zaps that already use the old connection. You must open each affected Zap, change its Zendesk step to the new version and connection, remap any changed fields, test the step, and publish the Zap.

Will switching to OAuth change what my Zaps can do?

The core triggers and actions stay the same, but the field set and output data of a step can change between integration versions. Review every field after the upgrade and remap downstream steps that used the old outputs, then run a test before you publish.

How do I know whether my Zendesk connection is already on OAuth?

Open My Apps in Zapier, select Zendesk, and look at the connection details. A connection on the older integration version shows a version number such as 1.x.x with a Legacy or Deprecated tag, while a connection with no such tag is likely already on the current OAuth based version and needs no action.

Conclusion

The Zendesk API token deprecation is a deadline with a known fix, not a mystery outage. Audit your connections, add an OAuth connection, upgrade each Zap individually with a field review and a test, observe the results for a day, and only then remove the legacy connection. Start with your least critical Zap today, while the April 30, 2027 deadline still leaves room to do the job properly. If you are building new automations rather than rescuing old ones, read our guide to Zapier durable workflows that keep running after you close the chat next, and if an earlier migration left you with deprecation warnings elsewhere, our walkthrough of fixing Zapier function deprecations covers the same upgrade one Zap at a time discipline. For teams weighing whether Zapier is still the right home for these automations at all, our Zapier to n8n migration guide compares the two paths. The same deadline-migration discipline applies to event platforms: our RunSignup Zapier API registration token migration walks through moving RunSignup Zaps to the new API Caller token before the legacy authentication expires.

Frequently asked questions