Protected customer data
Shopify is introducing updated requirements for apps that use customer data. As of version 2022-10 of the Admin API, published, public apps must meet the protected customer data requirements. Existing apps have until July 1, 2023 to migrate to API version 2022-10.
Privacy and data protection are critical foundations for ecommerce and are important to merchants and their customers. The protected customer data requirements focus on data minimization, transparency, and security so that you can better support a merchant's path towards compliance with privacy and data protection rules.
When your app uses API version 2022-10 or later, the review process for your public, published app might require action as described in the following table:
|Level||Data use||Partner actions|
|0||No customer data||No action required|
|1||Customer data excluding name, address, phone, and email fields||
|2||Customer data including name, address, phone, or email fields||
Shopify will approve your app to use protected customer data if the requested data is the minimum amount required by your app to provide the merchant with the app functionality. If you're approved to access the data that you requested, then code updates aren't required. If you aren't approved to access the data that you requested, then you might need to update your app to handle errors or redacted data. For more information, refer to the example API requests for protected customer data.
While we encourage all apps to meet protected customer data requirements, the requirements aren't mandatory for the following apps:
- Custom apps
- Unpublished testing apps or apps that are installed only on development stores
To access customer data in development, select the data and fields you're using in the Partner Dashboard. You don't need to submit your request for review for unpublished testing apps or apps that are installed only on development stores.
The following table provides our roadmap for implementing API version 2022-10 and the protected customer data requirements:
|June 22, 2022||Announcement of protected customer data requirements.|
|June—August 2022||APIs and reference docs for resources that contain protected customer data are published to the unstable and 2022-10 release candidate versions.|
|October 1, 2022||API version 2022-10 is released. Apps that use API version 2022-10 must meet the protected customer data requirements, and request any additional access in the Partner Dashboard.|
|April 2, 2023||New apps must use API version 2022-10 or later and meet the protected customer data requirements.|
|July 1, 2023||All apps must use API version 2022-10 or later and meet the protected customer data requirements. Admin API version 2022-10 is the minimum supported version.|
Request access to protected customer dataAnchor link to section titled "Request access to protected customer data"
As of API version 2022-10, you'll need approval to access protected customer data on any store that isn't a development store. Starting October 1, 2022, you'll be able to request access to protected customer data and protected customer fields through the Partner Dashboard.
Protected customer data includes any data that directly relates to a customer or prospective customer, as represented in the API resources. Resources that don't refer to a single customer, such as the product, theme, or inventory resources, are not included.
In addition to requesting access to protected customer data, you'll need to request access to the following protected customer fields individually because they directly identify customers:
- Name: first and last names
- Address: address line 1, address line 2, geolocation, and zip codes in both billing and shipping addresses
If your access is approved, these fields will appear in the protected customer API resources.
To request access:
From the Partner Dashboard, go to Apps, and then select your app.
In the sidebar, click App setup.
Find Protected customer data access and click Request access.
Select Protected customer data, provide your reasons for using it, and click Save.
If your app needs access to protected customer fields, then select the relevant fields, provide your reasons for using them, and click Save.
Complete your Data protection details, making sure that your app meets the protected customer data requirements.
Click Submit for review.
If your app is for testing or installed only on a development store, you can access customer data in development after Step 5. You don't need to submit for review.
You'll receive updates about the status of your review by email and through your Partner Dashboard. If you're updating to 2022-10 from an earlier API version, then make sure your access is approved before you update your code.
Migration guideAnchor link to section titled "Migration guide"
Develop and test: Configure your test app to access any required protected customer data. Shopify approval isn't required for apps in development. Update your test app using the new API versions and any new functionality to ensure that everything works as intended.
Submit for approval: Configure your production app to access the required protected customer data and submit for approval.
Deploy: After your request has been approved, deploy your updated production app to use API version 2022-10.
Protected customer data API resourcesAnchor link to section titled "Protected customer data API resources"
The REST Admin API and GraphQL Admin API docs define which resources and fields are protected customer data.
The following table summarizes the API resources that are considered protected customer data.
|API Resources||Protected customer data|
|Customers||Data that defines facts about a single customer, including name, addresses, email, and phone number.|
|Shipping Rates||Shipping rates that related to a single order, which relates to a single customer.|
|Events, Webhooks and Metafields||Events and metafields that relate to a single customer or order.|
|Orders||Orders, draft orders, abandoned checkouts, refunds, transactions, and other resources that relate to a single customer.|
|Checkout||Checkout and payments that relate to an order by a single customer.|
|Shipping and fulfillment||Shipping and fulfillment data that relate to orders by a single customer.|
|Online Store||Comments on a store that contain data about the commenter.|
|GiftCards||Gift cards that are used by a single customer.|
Using protected customer dataAnchor link to section titled "Using protected customer data"
After your app is approved to access protected customer data, API requests and webhooks that contain protected resources will return the data requested. Responses will include only approved fields, and unapproved fields will be redacted.
API requests to unapproved resources will return an HTTP
403 Forbidden reply.
Example API requests for protected customer dataAnchor link to section titled "Example API requests for protected customer data"
The following examples show API requests and responses for an app that is approved to access protected customer data and the
name fields. In this scenario, the
address fields are redacted from the REST and GraphQL replies. The GraphQL reply also includes an
errors message with an explanation of redacted fields.
REST requestAnchor link to section titled "REST request"
GraphQL request with approved fieldsAnchor link to section titled "GraphQL request with approved fields"
GraphQL request with unapproved fieldsAnchor link to section titled "GraphQL request with unapproved fields"
RequirementsAnchor link to section titled "Requirements"
To help apps safely process protected customer data, you must implement the following requirements in your development practices and in your apps. These requirements reflect the minimum acceptable handling of protected customer data and help apps support merchants with increasingly strict privacy and security requirements. You might need to consult with a privacy or legal professional for help applying these requirements to your business.
If you're using only protected customer data, then you must meet the level 1 requirements.
If you're using protected customer data including name, address, phone, or email fields, then you must meet all of the level 1 and 2 requirements.
Level 1 requirements:
Process only the minimum personal data required to provide app functionality to merchants.
Processing personal data comes with legal and regulatory requirements to secure, monitor, manage, and communicate about the data. Using the minimum data required helps minimize the time and effort spent complying with these requirements, and limits the potential damage of a data breach or unauthorized access.
Inform merchants what personal data you process and your reason for processing it.
Limit your processing of personal data to the stated purposes.
Processing must be limited to the stated purposes to ensure that merchants and customers are correctly informed about how their data is used.
Where applicable, respect and apply customer consent decisions.
Customer consent is a critical mechanism for customers to participate in their data processing and might be required depending on the type of processing your app performs.
Where applicable, respect and apply customer decisions to opt out of any data sharing such as a ‘data sale’ or similar concept under applicable laws or regulations.
Merchants must comply with applicable laws and regulations around sharing of personal data and this requirement helps ensure you are prepared to support them.
If you use personal data for automated decision-making and those decisions might have legal or significant effects, then you must allow customers to opt out.
Automated decision-making can include personal data processing such as profiling, analyzing, predicting, or scoring algorithms. Automated decisions with legal or significant effects are those that have a material impact on people's lives and it's important to give customers the option to have their data manually processed.
Make privacy and data protection agreements with your merchants.
Data protection agreements or privacy policies represent an agreement about personal data processing and are an important tool for formal and safe data privacy practices. They often include details such as data transfer mechanisms, scope of data processed, legal roles and responsibilities, retention, and definition of terms.
Apply retention periods to make sure that personal data isn’t kept for longer than needed.
Personal data must not be kept longer than necessary for the stated processing purposes. Retaining personal data longer than necessary increases the security risk of unauthorized access or inappropriate processing.
Encrypt data at rest and in transit.
Encrypting data when stored and as it transits various networks helps to prevent bad actors from gaining access to it even if they have access to the application. It also reduces the consequences of unintentionally disclosing the data set to the general public.
Level 2 requirements:
Encrypt your data backups.
Data backups can contain personal data and should be treated with the same level of concern and consideration as production data in order to prevent unauthorized access.
Keep test and production data separate.
Strict separation of environments prevents personal data from production from leaking into less secure environments where it could become exposed.
Have a data loss prevention strategy.
A data loss prevention strategy is a combination of technical controls, polices, and standards that protect an organization from the possibility of a bad actor extracting data for nefarious purposes.
Limit staff access to protected customer data.
Limiting staff access to protected customer data minimizes the risk that data will be improperly accessed, exfiltrated, or processed.
Require strong passwords for staff accounts.
Strong password requirements often include minimum length and a mixture of numbers, letters, and special characters.
Keep an access log to protected customer data.
Keeping logs and reviewing them frequently allows an organization to not only keep an audit trail of activity related to data access, but also assess whether their security controls are working effectively.
Implement a security incident response policy.
A security incident response policy helps organizations respond appropriately to security incidents and/or data breaches. These policies often include incident severity scales, roles and responsibilities, escalation paths, evidence collection, and required actions.
Data protection reviewAnchor link to section titled "Data protection review"
To help you meet the protected customer data requirements, we might ask for a detailed review of your practices. During this review, you'll need to provide evidence that your app and your practices meet the protected customer data requirements. If we select your app for a data protection review, then we'll contact you with instructions on how to proceed. Data protection reviews can occur after you've implemented the protected customer data requirements.
While any app might be selected, data protection reviews will likely focus on apps that have:
- High number of merchant installs
- High volume of customer records
- More protected customer fields approved
- Long retention of personal data