New deliveryProfile graphql queries

GraphQL Admin API Troubleshooting
1

Regarding New APIs to read and write shipping options in delivery profile - Shopify developer changelog

Whilst the new functionality is welcomed, the new query structure adds several levels of depth and makes querying for shipping rates highly inefficient.

Previously with Rest, we can pull all rate and zones in a single request.

With the current stable versions of graphql, we can still do this for stores with a reasonable number of profiles, location groups, zones and rates, but this new structure adds another two levels of depth and prevents us from being able to look up everything in one query.

The pagination functionality doesn’t really help when we need to paginate at different depths and ultimately requires a number of different queries, we want to try and avoid running bulk queries as well here as we’re just trying to work out which zones our carrier service app hasn’t been added to so we can notify the user.

I understand methodDefinitions.rateProvider hasn’t been deprecated yet but i’d imagine it will be some point down the track, in view of this, can the new structure be simplified somewhat to reduce the depth required or perhaps we can have locationGroups on the query root so we can look them up directly?

3

Hey @Min_Liu :waving_hand: Thanks for raising your concern about the added depth - it’s definitely valid.

The existing rateProvider and methodConditions fields are still available on all stable versions and described as “scheduled for deprecation” with no concrete timeline. There’s no urgency to migrate your reads right now.

For your specific use case of checking which zones your carrier service has been added to, the REST ShippingZone endpoint (GET /shipping_zones.json) returns all zones, rates, and carrier_shipping_rate_providers in a single flat response. REST is a legacy API and unavailable for new public apps created after April 2025, but since your app predates that cutoff it’s the most efficient option for this particular lookup.

I’ve logged the feedback about needing a flatter entry point for this data (e.g., locationGroups at the query root) as a feature request internally so the delivery team has visibility on the impact for carrier service apps.

1 Like