In the first week of November 2026, two platforms announced that a connection to them now expires if you don't use it. On 6 November Shopify wrote: "Apps that haven't run a bulk query or bulk mutation in the last 31 days lose access to that operation type." Zendesk announced the same day that its Salesforce integration's token, from 9 November 2026, "expires if the integration goes 30 consecutive days without being used."
Neither change will touch a connection that is used every day. The connection at risk is the one your code calls rarely: the quarterly reconciliation, the yearly price update, the restore script you have only ever run in a test. It passes every check you run, and then fails on the one morning you need it.
What Shopify changed
The Shopify entry is dated 6 November 2026: "Starting today, apps need access to bulk operations before they can run bulk queries or bulk mutations with the GraphQL Admin API." Access is granted separately for bulk queries and bulk mutations. Without it, "the request returns an access denied error", and "The requirement applies to all GraphQL Admin API versions."
- Who it applies to: public apps and partner-built custom apps. Shopify says "Apps that merchants create in the Shopify admin or the Dev Dashboard aren't affected at this time." This is a rule for app developers. A merchant using an app has nothing to change.
- Apps already using bulk operations were given access automatically. The 31-day rule is what takes it away again.
- To get it back, the developer opens the app in the Partner Dashboard, selects API access requests, and turns on the bulk operation types the app needs. Shopify says this needs no code change, no new app version and no reinstall by merchants.
Shopify publishes the same text under two changelog addresses, one for apps and one for partner apps. It is one change.
What changed for Zendesk and Salesforce
The Zendesk announcement was published on 6 November 2026 and the change takes effect on 9 November 2026. It covers the Zendesk Salesforce integration: "From November 9, 2026, that token expires if the integration goes 30 consecutive days without being used. Each time the integration is used, the 30-day clock starts again."
The rule comes from Salesforce, not from Zendesk. Zendesk explains: "Salesforce now requires apps that connect to its platform to expire unused access after 30 days of inactivity." Zendesk is meeting a requirement set by the platform it connects to. We have not read Salesforce's own wording of the requirement, so this article describes it only as Zendesk does.
Zendesk counts the integration as used when a data sync runs, when an agent opens Salesforce data in a ticket, or when an agent uses the Salesforce sidebar app. Its advice is that "For most customers, no action is required". If the connection does expire, you disconnect the integration in Zendesk Admin Center and reconnect it by signing in to Salesforce again. "Settings are saved following reconnection, you'll just need to re-enable the features you want to use."
Three different clocks
These are easy to blur together, so here they are side by side, with a third expiry we covered recently:
| What expires | Whose rule | When | How to restore it |
|---|---|---|---|
| An app's access to bulk queries or bulk mutations (each type separately) | Shopify, for public and partner-built custom apps | No bulk operation of that type in the last 31 days | App developer re-enables it in the Partner Dashboard |
| The Zendesk–Salesforce integration token | Salesforce requirement, applied by Zendesk from 9 November 2026 | 30 consecutive days without use; each use restarts the count | Disconnect and reconnect in Zendesk Admin Center, then re-enable features |
| A whole Vercel project | Vercel, only when you opt in with a flag | A duration you choose when the project is created | Cancel beforehand with vercel project keep |
The first two take away access because nobody used it, and nobody chose that. The Vercel one deletes a project because its owner asked for that. Our article on Vercel's project expiry flag covers that one.
If you have read our hosting comparisons, "inactivity" there meant something else: free-tier services that stop running when they get no traffic and take a few seconds to start again. Nothing is revoked in that case. Here the access itself is gone, and it stays gone until a person restores it.
Why the rare job is the one that breaks
A daily sync resets these clocks every day, so it never notices them. A job that runs every 90 days always finds its access more than 30 days old. With a rule like these two, a job that runs less than once a month will usually find its access gone. It is not a matter of luck.
This is not the question we looked at in where a scheduled job lives. That article was about where a schedule is defined. This one is about the credential the job uses when it runs, which can go stale even when the schedule is fine.
What to do about it
- List everything your apps use to connect to another service. API tokens, OAuth connections, granted scopes and app permissions all count. Include the ones only a script uses.
- Next to each one, write how often it is actually used, not how often it could be. "Once a quarter, by the reconciliation job" is the useful answer.
- Treat anything used less than once a month as a separate risk. For each of those, find out whether the provider expires unused access, and after how long.
- Test it early, not on the day. A few days before a rare job is due, run its first real call: a small bulk query for a Shopify app, or a sync for an integration. If access has gone, you find out while there is still time to restore it. That trial run also counts as use, so it restarts clocks like Zendesk's.
- Make a denied response fail loudly. An access denied error from a job nobody watches should alert someone. It should not end up as one line in a log.
- Write down how to restore each one. For Shopify, it is the Partner Dashboard page above. For Zendesk and Salesforce, it is disconnect, reconnect, then re-enable features. Whoever is on call should not have to search for it.
For example, if the quarterly job runs on the 10th, the early test can be one extra line in a crontab that runs on the 1st of the same month:
# quarterly job runs on the 10th of Mar/Jun/Sep/Dec; test its API access on the 1st
0 9 1 3,6,9,12 * /srv/app/bin/check-quarterly-access || /srv/app/bin/alert "quarterly job: API access check failed"The script and alert command are placeholders for your own. The point is the date: nine days before the real run, not on the morning of it.
Sources: Shopify developer changelog, "Apps must enable bulk operations before use", dated 6 November 2026; Zendesk, "Announcing a 30-day inactivity timeout for the Salesforce integration", announced 6 November 2026, effective 9 November 2026. Both read in full on 8 November 2026.