Shopify Community AMA with Shopify Developers: The New GraphQL Product APIs

Topic summary

Live text AMA held Oct 22 (11am–1pm ET) focused on the new GraphQL Product APIs (supporting up to 2,000 variants) and related REST deprecations, with links to docs, FAQ, and rules.

Key updates and decisions:

  • Publishing permission backfill: Submit the Publishing Permission Request form to backfill read_publications/write_publications for existing installs. Backfills run weekly (Fridays, except Dec 27) until Feb 1, 2025, and require existing read_products/write_products scopes and updated scopes for new installs.
  • Mutations: productCreate/productUpdate/productSet aren’t being deprecated; some fields are. Use productCreate/productUpdate + variant mutations for real-time; use productSet for syncing.
  • Webhooks: Currently REST-shaped; Shopify is considering a path forward for GraphQL consistency. No specific plans yet; feature request captured.
  • Channels: You can recreate a product feed via the products query using publishable_status filtering.
  • BulkOperations: Nested connections preserve response order; contact support if out-of-order is observed.

Open/ongoing issues raised:

  • 10,000 product query cap; need limiting in BulkOperations; whether GraphQL is required for Built for Shopify.
  • read_inventory backfill and access to moved variant fields.
  • Ajax Product API pagination beyond 100 variants.
  • MediaImage vs ProductImage migration and duplicate handling.
  • Contextual pricing performance/permissions and REST vs GraphQL price inconsistencies.
  • Webhook format options and topics for variants/options/images; media image edit events.
  • Shorter signed URL expiry for BulkOperations.
  • Adoption and distribution stats for >100 variants.
  • Non‑ASCII handles updates.
  • Barcode query delays/stale results.

Status: AMA closed; Shopify will continue answering submitted questions; many items remain under review or pending responses.

Summarized with AI on December 16. AI used: gpt-5.

Multiple calls turn real time into wait times.

multiple calls & real time & scale are three conflicting concepts.

A real time scenario is product customization apps et al., apps that create products at time of cart/pre-checkout.

Which already have a very common problem of needing to inject a loading animation to stall out the user experience as it’s not just the shopify api that has to be worked and waited on as there’s also checking the product is actually available on the frontend to update media or to avoid checkout issues.

And that’s in REST when publication is already part of the call, and if inventory/locations/markets isn’t involved.

Without being able to make a singular call to make a singular usable resource this is a step backward.

This seems like it will encourage more product generating apps towards using custom-line items on orders so they can give the perception of “real time” instead of dancing with an atomized product api; shifting the issue to holes in analytics and reporting etc.

Graphql’s strength is supposed to be query only the data you need where you need it, but somehow the other side of that equation in mutations is being made to be more complicated than all the lessons that were learned with the REST api partners had to push for.