Shopify made a small change on 6 November that could quietly break a job you've forgotten about. Apps now need permission to run bulk operations before they can use them. If your app already runs them, Shopify has switched it on for you. If it only runs them occasionally, that's where it gets interesting.
Bulk operations are how a lot of Shopify integrations do their heavy lifting. Exporting every product for a feed, pulling a year of orders into a reporting database, pushing thousands of price or stock changes in one go. If you've got a custom app talking to an ERP, a warehouse system or a marketplace, there's a fair chance it uses them somewhere.
What Shopify actually changed
The changelog post is short. From 6 November, an app needs bulk operations access before it can call bulkOperationRunQuery or bulkOperationRunMutation. The two are enabled separately, so an app that only reads in bulk doesn't automatically get to write in bulk too.
If an app tries to start a type of bulk operation it hasn't been given, the request comes back with an access denied error. It applies to all GraphQL Admin API versions, so you can't dodge it by pinning an older one.
Shopify has been sensible about the rollout. In its words, "If your app already runs bulk operations, then we've already enabled access for it." You don't need to change your app config, release a new version or ask anyone to reinstall. When you do need to switch it on, it's a few clicks in the Partner Dashboard and it then applies to every store that has the app installed.
Who it affects
According to Shopify's bulk operations guide, this covers public apps and custom apps that were created by a Partner. So if a developer or agency built you a custom app through their Partner account, it's in scope.
Apps that a merchant creates directly in the Shopify admin or the Dev Dashboard don't need to do anything "at this time". That last bit is worth reading as "for now".
The 31-day catch
This is the bit I'd pay attention to. The docs say that if your app hasn't started a bulk query or a bulk mutation in the last 31 days, you need to enable that type again before it can use it.
Think about the jobs that don't run every day. A quarterly stock reconciliation. A big price update you only do before the January sale. A full catalogue re-sync that someone kicks off by hand when things drift. A migration script that ran once in the spring and is due to run again when the next brand moves across.
Any of those could have lapsed. Then the job runs, Shopify says no, and what happens next depends on how the code handles a refusal. In a well-built integration, someone gets an alert. In a less careful one, the job logs an error nobody reads and the prices simply don't change.
What I'd check this week
None of this is hard, but it does need someone to actually look. Here's the order I'd go in:
- Find every bulk call. Search the codebase for bulkOperationRunQuery and bulkOperationRunMutation. Note which app each one belongs to, which type it is (query or mutation), and how often it runs.
- Check the Partner Dashboard. Go to Apps, pick the app, then API access requests. Under "Run bulk operations" you'll see whether queries and mutations are enabled. Switch on what you need.
- Look hard at the infrequent jobs. Anything that runs less than monthly is the one at risk. Either enable it now or make sure whoever triggers it knows what to do if it's refused.
- Make failures loud. A bulk operation that's refused should raise an alert, not just write a line to a log file. If you poll for status from a cron job, check what it does when the operation never starts at all.
- Write it down. Which apps use bulk operations, which types, and where the switch lives. The person who built it may not be the person who has to fix it.
We wrote up a pattern for handling bulk queries and mutations in PHP back in June, with a job queue and cron polling. It's a decent reference if you want to see what sensible error handling around these calls looks like.
It's part of a bigger tidy-up
This didn't come out of nowhere. Shopify's latest app security update also makes the IP allowlist compulsory for public apps. Public apps that use bulk operations need one by 12 November, or their bulk queries and mutations get blocked. Every other public app has until 20 November. Custom apps aren't covered by the allowlist requirement, but I'd still turn it on. I covered how it works when it first appeared in Shopify Can Now Lock Your App's Token to Your Servers.
The same post says bulk operations are getting their own access scopes soon, one for queries and one for mutations. Apps that ran a bulk operation in the last 180 days will get them automatically, and Shopify wants developers to add the scope names to their app config before the next deploy. The names haven't been published yet, so there's nothing to do today except make a note.
The direction is clear. Bulk operations can read or change a whole store in one request, which makes them just as useful to anyone who gets hold of your token. Shopify is adding locks, and your integration needs to know about each one.
If nobody's quite sure
The awkward case is the app that was built a couple of years ago, works fine, and nobody has opened since. You might not know which Partner account it lives in, let alone whether it runs bulk mutations once a quarter. That's the sort of thing that bites when the platform underneath changes.
If that sounds familiar, our code audit is £250 + VAT and tells you what you've actually got, including how your Shopify integrations talk to the platform and what happens when a call fails. If you'd rather someone else kept an eye on it, our Look after it service starts from £355 a month + VAT and covers the fixes, security updates, hosting and backups for software we build or take on. And if you're curious how I keep an eye on scheduled jobs and servers, I wrote about building my own server monitor over on my own site.
Either way, have a quick look in the Partner Dashboard this week. It's five minutes now or a confusing morning in January.
Cheers, Rob
