Delivery customization Admin API query returning empty results despite existing customizations

Shopify Plus
,
1

Hello,

We’re having Sandbox Plus store with multiple delivery customizations enabled, from different apps

We have a metafield attached to delivery customization which we need to populate on some conditions via scheduled workers

Once we run worker with app credentials with read_delivery_customizations

scope enabled, the response is empty for the following query:

query {
  deliveryCustomizations(first: 10) {
    edges {
      node {
        id
        title
        metafields(first: 10) {
          edges {
            node {
              id
              namespace
              key
              value
              type
            }
          }
        }
      }
    }
  }
}

Meanwhile, when we execute the same query in native graphQL application, the result is full and correct

Is there some misconfiguration or something else? Thank you in advance

2

The difference is because your worker uses app credentials, which are sandboxed to your app’s delivery customizations only. The GraphQL admin tool uses store owner credentials with global visibility.

3

Hi @PavelG

This behavior is not a misconfiguration but is the intended design of Shopify’s API for security and data isolation between applications. The core issue is that an application can only query the delivery customizations that it has created itself.

Even with the correct read_delivery_customizations scope, the GraphQL API automatically filters the deliveryCustomizations query to return only the nodes that are owned by the specific app making the request.

Since your scheduled worker is running with the credentials of your app, it can only see customizations created by that same app. The customizations created by the other apps on your store will not be visible to it, which is why you are receiving an empty response.

The reason it works in the native GraphQL application is that the execution context is different, and it is likely querying the customizations owned by all the different apps installed on the store.

Hope this helps!

4

It sounds like your query itself is fine since it works in the native GraphQL app, so the issue is most likely related to app permissions / token scopes rather than the query. A couple of things you might want to double-check:

  • The worker app should have the read_delivery_customizations scope, but if you’re also trying to pull metafields attached to those customizations, you may need to explicitly include read_metafields in the app’s access scopes.

  • Make sure you’re using the Admin API credentials (not the Storefront API), since delivery customizations and metafields won’t be exposed through the Storefront side.

  • If you recently updated scopes for your app, try reinstalling the app in the sandbox store so the new permissions take effect.

  • Compare the token being used in the worker with the one from your GraphQL client test — it’s possible they’re not the same token or environment.

If you’ve already confirmed scopes and tokens match, it might be worth enabling request/response logging in your worker to see what’s actually being passed in the API call. Sometimes a silent auth mismatch returns an empty array instead of an error.

5

Hi Pavel,

Thanks for sharing the details. Based on what you’ve described, the difference most likely comes down to API scopes and app context rather than a misconfiguration of your query itself.

A few things to double-check:

  1. Access Scopes

    • The worker app will need not just read_delivery_customizations but also the relevant metafield scopes (e.g. read_metafields). Without this, the delivery customizations may return but their metafields will appear empty.

  2. App Installation Context

    • If the worker app is using its own set of credentials, ensure it is installed on the same store and has the same permissions granted as the app you’re testing in the GraphQL explorer. Sometimes the GraphQL explorer uses the “native” admin context, which has broader access than a custom/private app.

  3. Token Verification

    • Confirm that the access token your worker uses matches the app’s latest permissions. If you’ve recently updated scopes in the Partner Dashboard, the app needs to be reinstalled or the token regenerated.

  4. Store/Environment Consistency

    • Since you mentioned Sandbox Plus, confirm that the worker is pointed to the same environment/store as the GraphQL explorer session (sometimes requests go to a staging vs. production shop).

In short, your query is correct — the gap usually comes from scope or token context. I’d recommend adding the read_metafields scope to your worker app, then regenerating the token and re-running the query. That should align the worker’s response with what you see in the GraphQL app.

Let me know if you’d like me to share an example of the exact scopes setup or token regeneration process.

6

I’ve actually run into this same issue before when working with delivery customizations. The query itself is fine — the real blocker is that the worker app token only had read_delivery_customizations but not the metafield scopes.