Amazon's Data Protection Policy for sellers: what third-party apps may see about your buyers

Two documents that bind every app on your account

One clarification first: if you are a shopper wondering what Amazon does with your own data, that is Amazon's Privacy Notice, a different document. This article is for sellers who connect apps to their seller account, and it is our reading of the rules as a developer, not legal advice.

Every developer who calls Amazon's Selling Partner API accepts two policies. The Data Protection Policy (DPP) sets the security and retention rules. The Acceptable Use Policy (AUP) sets the behavioural rules: what a developer may ask for, and what they may do with what they get. Both are public, and both are worth ten minutes of your time, because they define the ceiling for any app that asks for access to your account.

The DPP has two layers. Section 1 applies to "all systems that store, process, or otherwise handle data vended and retrieved from the Amazon Services API", so to every app, even one that only reads your daily order count. Section 2 adds stricter requirements that only apply once an app touches PII. That split is the whole point of this article: an app that never receives buyer data lives in the lighter layer, and you can tell which layer an app is in from the roles it requests.

The AUP adds two sentences that matter for you. "Do not request access to or retrieve Information that is not necessary for your Application's functionality." And: "Do not request or share Amazon Portal usernames or passwords from Authorized Users." An app that wants your Seller Central password, or a role it cannot explain, is outside the rules before it has stored a single byte.

For European sellers the GDPR sits underneath all of this. The two overlap in spirit, with data minimisation and purpose limitation at the centre, but this article stays with Amazon's rules.

What counts as PII, including the postcode

The DPP defines personally identifiable information as "information that can be used on its own or with other information to identify, contact, identify in context, or locate an Amazon Customer or Authorized User". The list that follows is longer than most sellers expect: "name, address, e-mail address, phone number, gift message content, survey responses, payment details, purchases, cookies, digital fingerprint (e.g., browser, user device), IP Address, geo-location, postal code, or Internet-connected device product identifier".

Two things in that list deserve a second look. The first is the postal code. A postcode on its own feels harmless, but Amazon counts it as PII because combined with other data it can locate a person. The second is what is not on the list: an order line without any buyer field. The fact that someone bought two units of a SKU on amazon.de at 14:03 does not identify, contact or locate anyone.

The postcode trap in order notifications

Here is the detail we only found by building an app. Amazon's ORDER_CHANGE notification, the push message developers subscribe to for order updates, carries a DestinationPostalCode field in its order summary. A developer who writes that message to a database as it arrives now holds PII, and with it the full weight of DPP section 2: 30-day retention, encryption of PII at rest, vulnerability scans, penetration tests. A developer who drops the field before the message is stored stays in section 1. When you ask an alert or analytics app what it does with the postcode, you learn a lot from how quickly they understand the question.

Restricted Data Tokens: the gate in front of buyer data

Amazon does not hand PII to an app just because you authorised it. Buyer details come out of the Orders API only through what Amazon calls restricted operations, and the Tokens API documentation says it plainly: "Restricted operations return customers' Personally Identifiable Information (PII). You need an RDT to call a restricted operation." An RDT is a Restricted Data Token, a separate token the app must request for each restricted call, and Amazon only issues it to an application whose approved roles cover the restricted data in question.

In the Orders API data model, three objects carry the restricted marking: ShippingAddress, BuyerInfo (name, e-mail address, tax details) and BuyerTaxInformation. Everything else, from the order id and purchase date to status, marketplace, order total, SKU, ASIN, title and quantity, comes back without any token. That is what an order alert or a dashboard works with.

One nuance on the order id: it is not on Amazon's PII list and it comes back without a token, but you and Amazon can trace it to a buyer in Seller Central. We treat it as pseudonymous data and store only a keyed hash. And one nuance on the total: while an order is Pending, Amazon returns no prices at all, so an alert app shows an estimate until the amount is released.

The role model: what you approve when you connect an app

Roles are, in Amazon's words, "the mechanism by which the Selling Partner API (SP-API) determines whether a developer or application has access to an operation or resource". A developer applies for roles when they register; you see them again on the consent page in Seller Central at the moment you connect the app. What is not on that page, the app cannot call. We walk through that page step by step in our guide on how to connect an app to Seller Central safely.

Four roles are marked restricted: Direct-to-Consumer Shipping, Tax Invoicing, Tax Remittance and Professional Services. Amazon's roles page explains the label: "Restricted means that the role requires sensitive information, which might include personally identifiable information (PII). For these roles, you must provide additional information about your data use and security controls." Restricted roles are the ones that unlock Restricted Data Tokens. A label printing tool needs one. An invoicing tool needs one. An alert, a dashboard or a repricer does not.

The role an order alert needs is Inventory and Order Tracking, and its description ends with a sentence worth remembering: "Operations that require this role do not use PII required to ship an order." That is the role that returns orders, order items and sales metrics, and it lets an app subscribe to the ORDER_CHANGE notification for FBA and FBM orders alike.

One more mechanic: if a developer adds a role later, Amazon requires a new authorisation before the new role does anything, so you see a new consent page rather than a silent expansion of what the app can reach.

Retention limits and audits: what an app holding PII must do

If an app does receive PII, the DPP is specific about how long it may keep it. A developer "will retain PII for no longer than 30 days after order delivery and only for the purpose of, and as long as is necessary to (i) fulfill orders, (ii) calculate and remit taxes, (iii) produce tax invoices and other legally required documents, and (iv) meet legal requirements, including tax or regulatory requirements". So 30 days after delivery, with legal and tax obligations as the only reason to keep anything longer. The AUP closes the other door: "Do not use Personally Identifiable Information about Customers for any purposes other than merchant-fulfilled shipping or to meet legal requirements."

Non-PII order data has a different clock. A developer may keep it only as long as it is strictly necessary for the purpose you authorised, and must permanently delete all of it, including live copies, within 30 days after you revoke the authorisation or Amazon requests deletion. A daily sales counter you still use is such a purpose; a copy of your orders kept after you disconnected is not.

Then come the technical duties. Every developer must encrypt Information in transit with "secure protocols such as TLS 1.2 or higher", keep programmatic credentials such as API keys "encrypted at rest, accessible only to authorized personnel, and rotated at least once every twelve (12) months", and grant access on a need-to-know basis. Developers who hold PII must additionally encrypt it at rest, run "vulnerability scanning conducted at least every 30 days" and "perform penetration testing at least every 365 days". On top of that, Amazon reserves the right to audit a developer's systems and to ask for written certification of compliance. None of this is visible to you as a seller, which is exactly why the roles on the consent page matter: they tell you which of these duties the developer has taken on, and whether the app needed them in the first place.

Why an order alert app needs none of it

Think about what a cha-ching on your phone actually needs. That an order exists, so the app can count it once. When it was placed, so the alert can say how fast it was. On which marketplace, and roughly for how much, so the number on the screen means something. Perhaps the SKU or title, so you know which product just sold. Every one of those fields comes out of Inventory and Order Tracking without a Restricted Data Token, and none of them tells the app who bought.

Your buyer's name does not make the sound any sweeter, and their address does not make the alert arrive faster; what matters for speed is how the app checks for new orders, which we measured in how fast an Amazon order alert can be. An app in this category that asks for buyer data has either misunderstood the policy or wants the data for something else. Neither is a good sign. The same logic applies to most dashboards, and even to the official Seller app, whose notification behaviour we cover in what the Amazon Seller app does and does not notify.

How to check what an app requests, and what to do if it asks for more

You do not need to read a developer's source code to judge an app. Four checks cover most of it.

1. Read the consent page before you confirm. It lists every role the app requests, and the names of the restricted roles are telling: Direct-to-Consumer Shipping, Tax Invoicing, Tax Remittance, Professional Services.
2. Match each role to a feature you will use. Label printing justifies Direct-to-Consumer Shipping. Invoicing justifies Tax Invoicing. Alerts, analytics, repricing and inventory planning justify none of the restricted roles.
3. Open the developer's privacy policy and look for three answers: which fields are stored, where the servers are, and how long data is kept after you disconnect. Under the DPP the last answer must be 30 days at most.
4. Ask one question by e-mail: "Do you store any buyer data, and what do you do with the postcode in the order notification?" A developer who has read the policy answers in two lines.

If an app asks for more than its features need, do not confirm. The AUP forbids requesting information an application does not need, so you are not being difficult. If you already connected it, revoke it: in Seller Central open Apps and Services, choose Manage Your Apps, find the app, choose Disable authorization and confirm with OK. Amazon's documentation notes that the app "is disabled, but remains viewable on the Manage Your Apps page", so seeing it listed afterwards is normal. From that moment the developer has 30 days to delete your data. And if you were connecting the app to hear your sales in the first place, our overview of every way to get notified of an Amazon sale shows which options need no buyer data at all.