If you sell on Amazon and have ever needed a customer’s full address — to print a shipping label, ship a print-on-demand order, or include a personalized message — you have run into Amazon’s restricted data rules.

This guide explains what restricted PII means in SP-API, how Amazon’s Public PII Process works, and what it changes about which Amazon analytics tools you can actually use.

TL;DR: Amazon classifies customer addresses, gift messages, customizations and a few other fields as restricted PII. To access them through SP-API, a developer must clear Amazon’s Public PII Process — a months-long, multi-stage audit of encryption, retention, access controls, vulnerability management and incident response. Most analytics tools either skip this audit or work around it. If your business needs PII for shipping, customizations or compliance, you need a tool that has cleared it.

What “restricted” means in Amazon SP-API

Amazon’s Selling Partner API splits seller and vendor data into two tiers:

• Standard data — orders, inventory, fees, ads performance, listings, settlements, product reviews. Available with regular SP-API approval.
• Restricted data — customer names, addresses, phone numbers, buyer email aliases, gift messages, product customizations, order item names where customer details might be inferred. Available only after additional approval.

The dividing line is anything that could identify the customer behind an order. Amazon enforces this strictly because it has direct compliance exposure under GDPR, CCPA and similar laws.

The Public PII Process

Any developer who wants to read restricted data on behalf of sellers has to complete Amazon’s Public PII Process. The audit covers six areas:

• Encryption. Restricted data must be encrypted at rest with strong symmetric ciphers (AES-256 is the standard) and in transit with modern TLS.
• Retention. PII must be deleted within thirty days of order shipment unless there is a documented legal basis to keep it longer.
• Access controls. Only systems and people with a documented need can access PII. Every access is logged.
• Vulnerability management. Components handling PII must be scanned at least every 180 days, plus continuous monitoring.
• Incident response. A documented response plan, with regular tabletop exercises.
• Penetration testing. Annual third-party penetration tests on every component of the data flow.

Approval is renewed annually. Failing any area means losing access for every connected seller — so the bar is set deliberately high.

What you can do once you have PII access

For Amazon sellers and vendors, restricted data unlocks workflows that are simply not possible without it:

• Print-on-demand orders. Customer name and shipping address are needed to generate the shipping label and print artwork.
• Personalized products. Gift messages, engravings, monograms — all live in restricted fields.
• Shipping label generation. Same fields, different context.
• Compliance and tax workflows. Some jurisdictions require keeping address records for VAT, sales tax or customs purposes.
• Customer support tooling. Resolving issues often requires looking up the customer address against a real order.

Tools that do not have PII approval cannot do any of this on your behalf. They will either ask you to download data manually or quietly skip these features.

How the data flow works under PII rules

When a tool with PII approval needs to read a restricted field, the data flow has extra steps:

1. The tool requests a Restricted Data Token (RDT) from Amazon, scoped to the specific resource and the specific data points.
2. Amazon issues a short-lived RDT (typically valid for an hour).
3. The tool uses that RDT — not a long-lived bearer token — to read the restricted field.
4. The data is encrypted and access-logged on the tool’s side.
5. The data is purged within thirty days unless there is a documented legal basis to retain it.

This entire flow has to be implemented and proven before Amazon grants approval.

How DataDoe handles restricted PII

DataDoe completed Amazon’s Public PII Process and is approved to access restricted data on behalf of every connected seller. In practice this means:

• AES-256 encryption at rest, TLS 1.2 or higher in transit.
• RDT-scoped per-request access, never long-lived bearer tokens.
• Automated thirty-day PII retention enforcement with audit log records on every deletion.
• Annual third-party penetration tests, with reports on file.
• 180-day vulnerability scanning plus continuous monitoring.
• Documented incident response plan with regular tabletop exercises.
• Per-key scopes so each integration only sees the slice of restricted data it needs.

Full documentation is available on the Security page.

Frequently asked questions

How long does the Public PII Process take?

For most developers, several months from initial application to approval, depending on review queue and how mature the security setup already is. Re-applying after rejection adds more time.

Why do not more analytics tools clear it?

Cost and effort. Cleared infrastructure costs more to run, audits cost real money, and the renewal cycle never ends. Many analytics tools position around standard data only.

Can a tool show me some PII without approval?

No. Without approval, restricted fields come back blank or denied. There is no partial access.

Does PII access mean my data is less safe?

The opposite. PII-approved tools are required to operate at a higher security baseline than standard SP-API tools, with stricter encryption, retention and audit requirements.

The bottom line

If your Amazon business depends on customer addresses, gift messages or customizations — POD sellers, jewelry brands, customized merchandise, anything compliance-heavy — picking a tool with cleared restricted PII access is not a nice-to-have. It is the difference between automating your operation and copying CSVs by hand.

DataDoe is approved for restricted PII access. See how POD sellers use it or read the full security documentation.