Shopify Protected Customer Data: When You Need Approval

Last updated October 23, 2026 · By Chad Norris

If your Shopify app reads orders, customers or anything tied to a single customer, you need Protected Customer Data (PCD) approval, and it is a Partner Dashboard declaration separate from the API scopes. Without it, as Shopify documents, your queries return errors or redacted values or return redacted nulls, the app looks empty to a reviewer, and the submission stalls. If your app only reads products, inventory or other resources not tied to one customer, you likely need nothing. Disclosure: we build Shopify apps under Orbitloft (disclosure); “in our app” notes below come from our own logs.

What counts as protected

Shopify’s protected customer data documentation groups access into levels:

Protected data covers resources tied to a single customer: customers, orders, webhooks, metafields, shipping, fulfillment, checkout and gift cards, among others. The docs state that resources not tied to one customer, such as the product query, are excluded. So a stock-forecasting app that reads only order line items (SKU and quantity) is typically Level 1, and a returns or support app that shows names and emails is Level 2.

Symptoms before approval

Shopify documents the behavior: unapproved fields are redacted and come back as null, and GraphQL requests to unapproved types return HTTP 200 with an errors entry explaining the app isn’t approved. That is exactly why the failure is easy to miss.

What we saw in our app: products and inventory loaded, so the store looked connected, but the order query threw an error stating the app was not approved to access the Order object. The code caught that error into an empty series, so every product showed zero sales velocity and the dashboard labeled everything overstock with nothing at risk. We lost a cycle chasing a theory about the order date window before reading the server logs. Two lessons:

• Read the logs when a dashboard shows plausible but all-zero numbers.
• Don’t swallow API errors into empty results. Surface them. It is also a review risk, as covered in Why Shopify Rejects Apps.

How to request access

Per Shopify’s documentation, the sequence is:

1. Pick a distribution method for the app first.
2. In the Partner Dashboard, open your app and go to API access requests.
3. Under Protected customer data access, request access, select the data you need, and give your reasons.
4. Separately request each name, address, email or phone field you need, with reasons.
5. Complete the data protection details, then submit the app for review.

Shopify approves only the minimum your app needs, so don’t tick every box. Our notes record the same flow under the app’s customer-data page in the Partner Dashboard, and one important detail: in the form, selecting any personal-data field triggered the longer security questionnaire (16 questions in our case), while selecting none produced a short form. If your app only needs line items, don’t request personal fields.

The requirements you are attesting to

From the same Shopify page:

Level 1: process only the data needed for functionality; tell merchants what you process and why; use it only for stated purposes; respect customer consent and opt-outs where applicable; allow opt-out of automated decisions with significant effects; have privacy and data protection agreements with merchants; set retention periods; encrypt at rest and in transit.

Level 2 adds: encrypted backups; separate test and production data; a data loss prevention strategy; limited staff access; strong staff passwords; an access log for protected data; a security incident response policy.

Only attest to what is true. For the data loss prevention question, our notes record that we answered yes on the basis of a hosting provider’s encrypted backups and point-in-time recovery, and that answering no left a blocking banner on the app. That is our interpretation, not Shopify’s; if you have any doubt, read the requirement text and be honest, since Shopify can ask for evidence. It says it may request a detailed review and evidence, more often for apps with many installs, many customer records, many approved fields or long retention.

Save the form from the top-level save control. Our notes record that the in-form save did not always commit; confirm the status afterward.

Worked example: choosing the level

These are illustrative app types, not rulings from Shopify; Shopify decides based on what you request.

When a feature only needs a count or a SKU, build it that way. Every personal field you drop shortens the questionnaire and narrows what a Shopify review can ask about. If a field is optional, consider making it an opt-in feature rather than a requirement for every merchant.

Handling a denial or a delay

Shopify’s documentation says that if you are denied access you should update the app to handle the errors and redacted values, and that if you are approved no code changes are needed. Design for both from the start:

• Wrap every customer-tied query so an approval error produces a visible, specific message to the merchant, not an empty table.
• Show which feature needs which data, so a merchant understands why a number is missing.
• Make personal-data features optional where you can, so the core product still works with the narrower approval.
• Avoid storing personal fields you don’t need; the retention and encryption attestations are easier to keep when there is less to protect.
• Log access to protected data from day one. Level 2 requires an access log, and retrofitting one is harder than building it in.

Tell reviewers in your testing instructions which data the app reads and why, so a reviewer who sees a redaction understands it is an approval state, not a bug.

Development versus public distribution

Shopify says you can reach protected data in development once you have selected the data and fields in the Dashboard, and that apps installed only on development stores need no review submission. Our experience matched: after a short form with no personal fields, access to a dev store worked immediately and the dashboard populated with no code change. For a public listing, review applies. Check status in the Dashboard and by email.

Where this fits in shipping an app

PCD belongs before the listing and screencast stage. A reviewer testing your app on their store cannot see the feature working if the access is pending, which is a core-functionality failure. Do this in order:

1. List every query that touches orders or customers. Ignore the mandatory privacy webhooks, which every app has.
2. Decide the lowest level that works. Redesign if a name or email isn’t essential.
3. Submit the request and finish the questionnaire.
4. Confirm a real order query succeeds on a dev store with real orders.
5. Move on to the embedded app check and the listing.

Also remember scopes: Shopify’s App Store requirements say apps must request only the access scopes they need (requirement 3.2), and read_all_orders needs justification. If your approved data is narrower than your scopes, trim the scopes. Details on timing across the whole process are in what to expect from Shopify app review.

This is not legal advice. For privacy-law obligations in your merchants’ regions, consult a qualified professional.

Mistakes to avoid

• Assuming a granted scope means data will flow.
• Requesting every personal field “just in case”; Shopify approves the minimum needed.
• Testing only with sample data, which hides the approval error entirely.
• Leaving the questionnaire half-complete: a missing answer can leave a banner that blocks submission, as we found with the data loss prevention question.
• Forgetting that a second app in the same portfolio may query orders too. Audit each app’s queries separately.