Protected customer data access in "Draft" not honored on development stores — Admin GraphQL returns HTTP 403 on webhook subscription operations

GraphQL Admin API Troubleshooting
1

Our public embedded app needs to register webhook subscriptions for protected topics (ORDERS_CREATE, ORDERS_PAID, ORDERS_FULFILLED, ORDERS_CANCELLED, REFUNDS_CREATE, CUSTOMERS_CREATE) via the Admin GraphQL API using a token-exchange (new embedded auth) offline access token.

Symptom: On our development stores, every Admin GraphQL operation that touches protected customer data returns HTTP 403 {"errors":{"networkStatusCode":403,"message":"GraphQL Client: Forbidden"}}, while non-protected queries on the same endpoint with the same token succeed:

  • { shop { name } } → HTTP 200 :white_check_mark:
  • { webhookSubscriptions(first:1){edges{node{id topic}}} } → HTTP 403 :cross_mark:
  • webhookSubscriptionCreate(topic: ORDERS_CREATE, …) → HTTP 403 :cross_mark:

This worked previously when the app used custom/development distribution; it began 403-ing after the app moved to public distribution.

Everything in the documented setup is complete:

  • Partner Dashboard → API access requests → Protected customer data access: base access + all four fields (Name, Email, Phone, Address) selected, usage reasons provided, Data protection details completed (all questions). Status badge shows Draft (we understand from your team that Draft should not block development-store access).
  • Granted scopes on the install include write_orders (implies read_orders) and read_customers — verified in our session store.
  • Released a current app version (wafonic-4) and reinstalled — grant updated correctly, but the 403 persists.
  • Both stores are Development stores.

Question: Why is protected customer data access not being honored on our development stores despite the access being configured (Draft)? Is a review submission now mandatory for public apps even for development-store testing, or is this the known new-Dev-Dashboard PCD issue? How do we unblock webhook registration for protected topics?

2

Hi @Atif! You’re right that Draft status shouldn’t be blocking you here. For public apps, protected customer data access is granted on development stores once you select the data and fields in the Dashboard, no approval needed for dev-store testing. So the Draft label by itself isn’t the cause.

What stands out is the hard 403. When an app genuinely lacks PCD access, the Admin API returns HTTP 200 with the protected fields nulled out and an errors entry explaining the access gap, so a 403 Forbidden is already an unusual signal here. A blanket token problem would also fail your shop { name } call, but that returns 200, so the failures are landing specifically on the protected operations.

Can you grab the x-request-id response header from one or two of the failing webhookSubscriptions or webhookSubscriptionCreate calls and share those? The request ID lets me look up the logs for those calls and see where the issue actually lies - thanks!