Work with protected customer data

Public apps 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 types and resources. Types and resources that don't refer to a single customer, such as the product query, aren't 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
• Email
• Phone

If your access is approved, these fields will appear in the protected customer API types and resources.

To request access:

1. From the Partner Dashboard, go to Apps, and then select your app.

2. In the sidebar, click API access.

3. Find Protected customer data access and click Request access.

4. Select Protected customer data, provide your reasons for using it, and click Save.

5. If your app needs access to protected customer fields, then select the relevant fields, provide your reasons for using them, and click Save.

6. Complete your Data protection details, making sure that your app meets the protected customer data requirements.

7. Submit your app 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.

The GraphQL Admin API and Customer Account API reference documentation defines what types, objects, and fields represent protected customer data.

The following table summarizes the API types that are considered 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.

GraphQL requests to unapproved types will return an HTTP 200 Ok response with an error message in the errors hash.

The following examples show API requests and responses for an app that is approved to access protected customer data and the email and name fields. In this scenario, the phone and address fields are redacted from the GraphQL replies. The reply also includes an errors message with an explanation of redacted fields.

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:

1. 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.

2. Inform merchants what personal data you process and your reason for processing it.

   Transparency with merchants about what personal data is processed and why helps merchants manage what processing occurs on their behalf. This information is often included in your privacy policy or data protection agreement.

3. 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.

4. 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.

5. 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.

6. 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.

7. 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.

8. 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.

9. 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:

1. 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.

2. 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.

3. Have a data loss prevention strategy.

   A data loss prevention strategy is a combination of technical controls, policies, and standards that protect an organization from the possibility of a bad actor extracting data for nefarious purposes.

4. 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.

5. Require strong passwords for staff accounts.

   Strong password requirements often include minimum length and a mixture of numbers, letters, and special characters.

6. 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.

7. 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.

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