Security & Data Protection

TheSeller.app processes Amazon Selling Partner data on behalf of Amazon sellers. This page describes the technical and organizational security controls we maintain. The controls are designed to meet the requirements of Amazon's Selling Partner API Data Protection Policy (DPP), Amazon's Acceptable Use Policy (AUP), and the GDPR.

This document is a public summary of our internal Information Security Policy and is reviewed at least annually, after any material change to our infrastructure, and after any reportable incident. The Information Security Officer can be reached at security@theseller.app.

1. Acceptable Use Policy compliance

We acknowledge and comply with Amazon's Acceptable Use Policy as published at sellercentral.amazon.com. We:

• Use Amazon Information solely to provide the analytics services that the Selling Partner has explicitly authorized.
• Do not sell, lease, trade, redistribute or repurpose Amazon Information; do not combine it with data from other sources except to render the authorized service for the same Selling Partner.
• Do not use Amazon Information to train any machine-learning or artificial-intelligence model.
• Do not contact Amazon buyers using Amazon Information for any unsolicited purpose.
• Honor data deletion requests from Selling Partners and from Amazon, and remove Amazon Information from all systems within 30 days of the triggering event.

2. Authorization and scope minimization

• Sellers authorize our applications through Login with Amazon (LWA) using Amazon's OAuth flow. No client secret leaves our backend.
• We request only the minimum SP-API roles necessary for the analytics features the seller signed up for, and we display each requested scope at consent time.
• Sellers can revoke our access at any time from within our application or from Seller Central → Apps and Services → Manage Your Apps. Revocation triggers token deletion (see §6).

3. Credential Management

Aligned with Amazon's Credential Management guidance.

• No plaintext credentials. Refresh tokens, client secrets, IAM credentials and database passwords are stored exclusively in a secrets manager (Vercel/Supabase encrypted environment), never in source control, never in plain logs.
• Encryption at rest. Refresh tokens are additionally encrypted at the application layer with AES-GCM using a key kept in our secrets manager and separated from the database.
• Access tokens. Short-lived SP-API access tokens live only in process memory for the duration of an API call. They are never persisted to disk and never logged.
• Rotation. Application secrets (signing keys, third-party API keys) are rotated at least every 90 days, immediately upon any suspected leak, and immediately when any team member with access leaves the organization.
• Least privilege. IAM roles and database roles grant only the permissions required by the workload they serve. Production credentials are not used in development or staging environments.
• Multi-factor authentication. All operator access to production consoles (cloud providers, repositories, secrets manager) is gated by SSO with mandatory MFA.
• Access logging. Operator access to production credentials and databases is logged and reviewed.

4. Network Protection Controls

Aligned with Amazon's Network Protection guidance.

• Encryption in transit. All public endpoints enforce TLS 1.2 or higher with modern cipher suites. HSTS is enabled with preload. Plain-HTTP requests are redirected to HTTPS.
• Encryption at rest. Application data, backups and object storage are encrypted at rest by the underlying providers; sensitive fields receive an additional application-layer encryption pass.
• Database isolation. The production database is not reachable from the public internet. Application servers reach it through provider-managed connectivity using credentials scoped to a least-privilege role.
• Edge protection. Public endpoints sit behind a CDN/edge layer with managed DDoS mitigation, automated TLS, and Web Application Firewall rules covering OWASP Top 10 categories.
• Rate limiting. Authentication, authorization and SP-API proxy endpoints are rate-limited per account and per IP to protect against credential-stuffing and brute-force abuse.
• Outbound calls. SP-API requests are made server-side from our backend; credentials are never exposed to browsers or other untrusted clients.
• Tenant isolation. Multi-tenant data is isolated through Postgres row-level security policies that constrain every query to the authenticated tenant.

5. PII Data Retention

Aligned with Amazon's PII Data Retention guidance. The default position of TheSeller.app is to not collect Amazon buyer-level Personally Identifiable Information at all.

• Minimization at ingest. Where SP-API responses contain PII fields by default (for example shipping addresses on order reports), our ingestion pipeline strips those fields before persistence. Only non-PII aggregates are stored.
• 30-day cap on any incidental PII. If buyer PII is unavoidably required for a feature the seller has explicitly authorized, it is retained no longer than 30 days after the order is shipped, after which it is permanently deleted from primary storage and rotated out of backups.
• Encryption. Any PII held at rest is encrypted with a separate key from general application data.
• No sharing. PII is never shared with third parties beyond the subprocessors listed in the Privacy Policy, all of which are contractually bound to equivalent safeguards.
• Deletion on disconnect. When a seller disconnects an Amazon account or deletes their TheSeller.app account, all derived data — including any incidental PII — is purged from primary systems within 30 days, and from backups within the next backup rotation cycle (≤ 90 days).

6. Token and data lifecycle on disconnection

• On user-initiated disconnection or revocation from Seller Central, our backend deletes the corresponding refresh token immediately and ceases SP-API calls.
• A scheduled job purges all derived Selling Partner records associated with the disconnected authorization within 30 days.
• Backups containing pre-deletion data are retained for at most 90 days, after which they are rotated out and irrecoverable.

7. Incident Management

Aligned with Amazon's Incident Management guidance. We maintain a written Incident Response Plan, owned by the Information Security Officer, reviewed at least annually and tested through tabletop exercises.

A reportable incident includes any of: unauthorized access to production systems, unauthorized disclosure or exfiltration of Amazon Information or personal data, malware or ransomware on systems that process Amazon Information, lost or stolen credentials with access to Amazon Information, and any event materially compromising the confidentiality, integrity or availability of the Service.

1. Detect & triage. Alerts from infrastructure, application logs and third-party monitoring are routed to an on-call rotation. The on-call engineer acknowledges within 30 minutes and triages within 2 hours.
2. Contain. Compromised credentials are revoked, affected systems are isolated, and emergency rotations are performed.
3. Notify.
   • Amazon is notified at security@amazon.com within 24 hours of detection where Amazon Information is, or may be, implicated.
   • The Estonian Data Protection Inspectorate is notified within 72 hours where required by Article 33 GDPR.
   • Affected users are notified by email without undue delay where the incident is likely to result in a high risk to their rights and freedoms.
4. Investigate. Logs are preserved, root cause is identified, and the scope of impact is determined.
5. Remediate. Fixes are deployed, controls are reviewed, and lessons learned are documented in a written post-incident report.
6. Post-incident review. A written summary is shared internally and, where appropriate, with affected users and Amazon.

8. Organizational change notification (Data Access 3.11)

We maintain a written policy requiring TheSeller.app to notify Amazon at security@amazon.com within 30 days of any organizational change that affects, or could affect, our need for or use of Amazon Information. The policy explicitly covers:

• Changes in legal entity, beneficial ownership, or controlling shareholder.
• Mergers, acquisitions, divestitures or restructurings.
• Changes to the Service that materially expand or change the categories of Amazon Information processed or the SP-API roles requested.
• Changes in the location of data processing, hosting providers, or any subprocessor with access to Amazon Information.
• Changes in the personnel role responsible for Amazon Information governance.
• Discontinuation of the Service or of an integration that uses Amazon Information.

The Information Security Officer is accountable for triggering the notification within the 30-day window and for keeping a record of every notification sent.

9. Personnel security

• New team members complete a written security onboarding before being granted production access. Onboarding covers credential handling, the Incident Response Plan, the Acceptable Use Policy, and the obligations of this page.
• Production access is least-privilege and is reviewed at least quarterly. Access is revoked within 24 hours of a team member leaving the organization or changing role.
• All personnel with access to Amazon Information are bound by written confidentiality obligations.

10. Software development lifecycle

• All changes to production code are reviewed and merged through pull requests.
• Dependencies are scanned for known vulnerabilities; high-severity findings are remediated.
• Static analysis and secrets scanning run on every commit; merges that introduce plaintext credentials are blocked.
• Production deployments are immutable and reproducible from version control; emergency rollback is available at all times.

11. Backups and business continuity

• The production database is backed up automatically by our managed Postgres provider.
• Backups are encrypted at rest in the same region as the primary database.
• Backup retention is capped at 90 days, after which backups are rotated out.
• Restore procedures are tested at least annually.

12. Reporting a vulnerability

We welcome coordinated disclosure of security vulnerabilities. Please email security@theseller.app with reproduction steps. We commit to:

• Acknowledging receipt within 48 hours.
• Providing an initial assessment within 5 business days.
• Fixing confirmed high-severity issues without undue delay.
• Crediting the reporter in our post-fix communication, on request.

Please do not test against accounts that are not your own, do not exfiltrate data beyond the minimum required to demonstrate the issue, and do not publish details before we have had a reasonable opportunity to remediate.

13. Contact

Information Security Officer: security@theseller.app.
Full legal entity, registered address and identifiers are listed on the legal information page.