Shopify bulk operations now require explicit access before affected apps can run them. If your store depends on a scheduled catalog export or a large product update, this is worth checking before the next job starts. Shopify’s November 6 announcement introduces separate access controls for bulk queries and bulk mutations. Here’s how to identify affected integrations, ask your developer the right questions, and restore interrupted work without creating a second problem.
What changed for Shopify bulk operations?
Shopify’s partner-app bulk operations announcement says apps need access enabled in the Partner Dashboard before they can start bulk queries or bulk mutations through the GraphQL Admin API.
The controls are separate. An app that needs to export data requires bulk-query access. An app that needs to perform bulk updates requires bulk-mutation access. Enabling one does not mean both are enabled.
- Bulk queries: access is required to run bulkOperationRunQuery.
- Bulk mutations: access is required to run bulkOperationRunMutation.
- Missing access: a request to start a bulk operation returns an access denied error.
- API coverage: the requirement applies to all GraphQL Admin API versions.
The notice names public apps and custom apps built by partners that run bulk operations. Merchants should ask their app provider to confirm applicability to their specific app, rather than assume every integration described as “custom” has the same requirements.
Changing to an older API version is not a workaround. The announcement explicitly covers all versions. The useful fix starts with the app’s access configuration.
Why this deserves attention amid the Fall ’26 releases
Shopify’s Fall ’26 developer overview describes opening its catalog, cart, and checkout to agents and apps, alongside tools for building and securing integrations. That broader direction makes app permissions a practical operating concern for merchants, even when the settings live outside their Shopify admin.
Our view: a store’s most urgent release task is often the least visible one. A new shopping experience can wait while you assess it. A permission requirement affecting tonight’s export may not.
This update deserves priority because it changes whether an affected job can start. It does not require a storefront redesign. It requires someone who owns the integration to check a specific setting and prove the workflow still completes.
Which store workflows should you investigate?
A bulk operation is an API workflow for handling large amounts of data asynchronously. In practical terms, an app can submit work and retrieve its outcome later rather than keep a normal request open throughout the task.
That does not mean every large import or export uses Shopify’s bulk-operation endpoints. A tool might use ordinary API requests or another supported mechanism. The size of the spreadsheet won’t tell you which.
Start with integrations that move substantial amounts of store data. Ask the owner of your product information system how it publishes catalog changes. Ask whoever maintains your reporting pipeline how it extracts records. Include migration utilities and internal scripts that run infrequently: a dormant tool can hide an access problem until someone urgently needs it.
For each workflow, record its business purpose and technical owner. Add the app responsible, whether it uses bulk queries or mutations, and the next scheduled run. A short inventory is more useful than a vague message asking everyone to “check Shopify.”
How to check Shopify bulk operations access
Give the app owner a precise request
Most merchants shouldn’t need to debug GraphQL requests. They do need a clear answer from the person or vendor responsible for them.
Does our integration call bulkOperationRunQuery or bulkOperationRunMutation? Please confirm the required access is enabled for the production app in the Partner Dashboard, then verify a representative job completes and its output reaches the intended destination.
That final clause matters. A successful API request is not the same as an updated downstream system. An export may start correctly while the process that downloads or imports its result still fails.
For a public app, contact the vendor. For a partner-built custom app, contact its developer. Don’t assume your store staff can resolve a Partner Dashboard setting from the merchant admin.
Check queries and mutations independently
An integration might read the catalog successfully but fail when it tries to write changes. Shopify treats bulk-query and bulk-mutation access separately, so a passing export test cannot prove that an import will work.
Match the enabled access to the app’s actual functions. We would avoid switching on bulk mutations for a reporting-only app simply because the option is available. Treat access as an intentional configuration decision, not a box-ticking exercise.
Also confirm that the developer checked the production app. Evidence from a development installation is useful during testing, but it does not establish the state of the app that serves your live store.
Verify the business outcome
For a query, confirm the operation completes and the expected data arrives where your team uses it. Compare the output with the intended scope of the export. An empty file should not count as success just because a file exists.
For a mutation, use a controlled, reversible change appropriate to the workflow. Check the intended records afterward and inspect any reported errors. Capture enough evidence to distinguish a permission failure from a problem with the submitted data.
If a job has failed, don’t blindly replay it
Shopify says a bulk-operation start request without access returns an access denied error. That tells you the attempted operation could not start. It does not tell you what the surrounding integration did before that request.
A synchronization workflow could have prepared files or changed records through other requests before attempting its bulk step. Establish where it stopped before restarting the whole workflow.
Our recommended recovery sequence is:
- Preserve the failure details. Keep the error response, app identity, and job timestamp so the developer can identify the failed step.
- Prevent repeated failed attempts. Pause the affected schedule or queue if retries keep returning the same access error.
- Correct access and test it. Have the app owner enable the required capability and verify a controlled operation.
- Reconcile before replay. Check completed work and current source data, then resume only the work that remains necessary.
Be especially careful with queued updates. If the source data has changed since the failure, replaying an old payload could overwrite a newer decision. The right recovery may be a fresh export from the source system rather than a retry of the original file.
This is also where idempotency matters. An idempotent workflow can repeat the same intended change without creating additional unintended effects. Ask your developer how the integration prevents duplicate work during recovery; don’t assume the word “retry” means safe.
Do you need a new app or a rebuilt integration?
Usually, the first question should be whether the existing app has the required access. The announcement describes an access requirement, not a blanket requirement to replace integrations.
We would be skeptical of a proposal to rebuild a functioning data pipeline before checking its configuration. Equally, a vendor saying “we’ve enabled it” should provide confirmation that your workflow works, not just that a setting changed.
Keep an existing tool if its owner can explain its bulk-operation use and demonstrate a successful recovery. Consider a deeper review if nobody owns the integration, its logs cannot identify failures, or failed work disappears without an alert.
Replacing bulk operations with ordinary requests solely to avoid this access control is not our default recommendation. That changes the integration’s execution model and may introduce different performance or API-limit concerns. Resolve the permission issue first; redesign only when there’s a separate business case.
Make the access check part of app handover
The lasting lesson is about ownership. Merchants often know which app handles catalog data but not who controls the developer-side configuration.
Add a short access record to your integration documentation. It should identify the responsible organization, the production app, and which bulk capabilities it needs. Include the escalation contact and a description of the test that proves the workflow works.
When an app changes hands or gains a new function, revisit that record. A reporting integration that later starts writing product changes needs a fresh review, even if its original export workflow still runs normally.
For now, prioritize affected jobs by business consequence and next execution time. Resolve the dependency your team needs next, then work through the rest. The goal is verified continuity, not a hurried rebuild.
Takeaways
- Shopify requires separate access for bulk queries and bulk mutations in affected partner apps.
- The requirement applies across GraphQL Admin API versions; downgrading won’t bypass it.
- Ask the app owner to verify production access and the complete business workflow.
- Before replaying failed jobs, reconcile completed work and check whether queued data is still current.
Sources
- Partner apps must enable bulk operations before use
- Bringing shopping into the future: The Fall '26 Edition ... - Shopify
Want this handled for you?
We're a Shopify Premier Partner and this is the work we do every day: performance, CRO, and store builds that pay for themselves. Book a free store review and we'll show you the three fixes we'd ship first.
Frequently asked questions
Why are Shopify bulk operations returning an access denied error?
Shopify’s November 6 announcement requires affected partner apps to have bulk-operation access enabled in the Partner Dashboard. Missing access causes a request to start a bulk operation to return an access denied error. Ask the app owner to check the relevant capability and inspect the actual error.
Are bulk-query and bulk-mutation permissions separate?
Yes. Bulk-query access is required for bulkOperationRunQuery, while bulk-mutation access is required for bulkOperationRunMutation. A successful export does not prove that bulk updates have the required access.
Can an older Shopify API version avoid the bulk-operation access requirement?
No. Shopify says the requirement applies to all GraphQL Admin API versions. The app owner should correct the access configuration rather than downgrade the API version.
Should I restart a failed Shopify bulk import immediately after enabling access?
First establish where the workflow stopped and whether any surrounding steps completed. Check that the queued data is still current, then test the corrected access and resume only the necessary work.
