If you’re reading this, you’ve probably stared at the Amazon SP-API developer application and thought: “do I really need to describe my incident response plan to sell bike parts?”

Yes. And here’s exactly what to write.

The application has four sections that matter

Amazon doesn’t auto-reject small companies. They auto-reject applications that look like the applicant didn’t read the questions.

1. Organization type: pick “Private”

Public apps appear in the marketplace. Private apps only talk to your own seller accounts. Unless you’re building a SaaS for other sellers, pick Private. It reduces scrutiny significantly.

You don’t need a GmbH or Inc. A sole proprietorship with a professional selling plan works. What Amazon cares about:

• You have a real seller account with order history
• Your website exists and matches the business
• Your contact email is a business domain, not gmail

Don’t use a free email address for the primary contact. Even info@yourdomain.com is fine.

2. Data access roles: only request what you can justify

Every role you check creates a new justification burden. Our approved application requested seven:

• Tax Invoicing, Pricing, Finance & Accounting, Inventory and Order Management, Product Listing — these are standard for any seller integrating their own backend
• Brand Analytics — only if you actually own a brand
• Direct-to-Consumer Shipping — only if you handle fulfillment yourself (not FBA)
• Professional Services — only if you offer assembly, installation, or warranty

The roles containing PII (DTC Shipping, Tax Invoicing, Professional Services) each need a dedicated justification. Amazon gives you a text box for each — use it.

3. PII justifications follow a formula

Three restricted roles. Three justifications. Amazon wants to know “why do you need the buyer’s name and address?” The answer is always one of:

• Legal requirement — German §14 UStG requires buyer name/address on every invoice. EU VAT rules require the same. Quote the law. It works.
• Operational necessity — you can’t print a shipping label without a name and address. Say that.
• Customer service — if you handle warranty claims or assembly scheduling, you need contact info. Describe the exact workflow.

A bad justification: “we need buyer data to serve customers.” A good justification: “buyer name and address retrieved via SP-API Orders API, transmitted via HTTPS to DHL Paket for label generation only, not retained after shipment confirmation.”

The difference is specificity. Amazon reads these.

4. The security questionnaire: don’t lie, but be complete

This is where most applications die. The 20+ questions about encryption, incident response, vulnerability scanning, and password policies are not optional flavor text. Each answer gets reviewed.

What works:

Question	What to write
Network security	”Hetzner dedicated server with UFW firewall. Ports 443, 80, and 22 only. PostgreSQL bound to localhost. Cloudflare WAF in front. SSH key-only auth.”
PII encryption	”AES-256-CBC at application layer. LUKS disk encryption (AES-256-XTS) at storage layer. Keys in OS environment variables, never in source code.”
Incident response	”Revoke compromised tokens within 1 hour. Isolate server via firewall. Email security@amazon.com within 24 hours. Post-incident review within 30 days.”
Password policy	”12 character minimum. Upper, lower, digit, special char required. bcrypt hashed. No reuse of last 10 passwords. 365 day expiration. MFA on all accounts.”
Vulnerability scanning	”Dependabot on every commit. OWASP ZAP scan before production deploys. Annual penetration test. Critical: 7 day remediation SLA.”
Credential storage	”SP-API credentials encrypted with Fernet (AES-128-CBC). Keys as OS env vars. .env in .gitignore. GitHub secret scanning enabled. No production credentials on dev machines.”
PII in testing	”Synthetic data only. Separate test database. SP-API Sandbox for integration tests. Production PII never used in dev environments.”
Backups	”Daily pg_dump to separate data center. Weekly snapshots to geographically separate region. 30 day daily retention, 6 month weekly retention. Quarterly restore testing.”
Access control	”Named accounts only. No shared credentials. Role-based access. Accounts deactivated within 24 hours of offboarding. Quarterly access review.”
Logging	”PII never in logs. Timestamp, endpoint, user ID, IP, response code only. 12 month retention. Bi-weekly log review. fail2ban for brute force.”

The pattern: name a specific technology, name a specific retention period, name a specific SLA. Vague answers get rejected.

5. The third-party data sharing question

Amazon asks if you share buyer data with anyone. Most sellers share with a shipping carrier and maybe a tax advisor. Say it explicitly:

“Buyer shipping address shared with DHL Paket GmbH via HTTPS API for label generation only. Not retained after shipment confirmation. Buyer name and order totals shared with DATEV-connected tax advisor for VAT filing per German HGB. No Amazon data sold, used for marketing, or shared with any other party.”

Listing the specific company name and the specific legal basis works better than “we share with shipping carriers.”

6. Hosting and infrastructure

Amazon cares where their data lives. A Hetzner box in Germany with Cloudflare in front will get approved faster than “AWS” because it’s specific. What to mention:

• Server location and provider
• Firewall configuration (specific ports, specific rules)
• Database access restrictions (localhost only, no public exposure)
• Authentication method (JWT, session expiry time)
• Whether admin panels are publicly accessible (they shouldn’t be)

The checklist before you submit

• Business email domain (not gmail)
• Real website with privacy policy URL
• Professional selling plan active
• At least one restricted role justified per PII access
• Every security answer references a specific technology
• Incident response plan includes security@amazon.com notification
• Third-party data sharing lists specific companies
• DPA or privacy policy URL is live and accessible
• Source code references: no hardcoded secrets, private repo, secret scanning on

What happens after submission

Amazon typically responds in 2-5 business days. If rejected, they’ll tell you which section needs revision. Fix that section only — don’t rewrite the whole application. Resubmit. Most approvals happen on the second attempt.

Once approved, your app gets Client ID and Client Secret. Rotate them annually. Use refresh tokens, not long-lived credentials. And set a calendar reminder for the renewal — SP-API tokens don’t last forever.