24/7 Profits — Amazon Data Protection Plan
Effective: May 25, 2026 · Version 1.0
Publisher: AllDayFBA LLC dba 24/7 Profits ("we," "us," or "the Company") Application name: 24/7 Profits Public website: https://247profits.org Privacy Policy: https://247profits.org/privacy Support contact: support@247profits.org Security contact: security@247profits.org
This Data Protection Plan describes the technical, operational, and organizational controls we apply to Amazon Selling Partner ("Amazon SP-API") information accessed through our application. It is published in compliance with Amazon's Acceptable Use Policy and Data Protection Policy, and is referenced by Section 14B of our public Privacy Policy.
1. Scope of Amazon Data Accessed
Through the Amazon SP-API authorization grant, our application accesses the following data sets and no others:
| Data set | Operations | Purpose |
|---|---|---|
| Orders | getOrders, getOrderItems (anonymized variant) | Profit calculation, fulfillment dashboards |
| Inventory | getInventorySummaries, getInboundShipments | Replenishment alerts, IPI tracking |
| Pricing | getPricing, getItemOffers, getCompetitivePricing | Buy-Box monitoring, repricer signals |
| Returns / Reimbursements | getReturns, FBA reimbursement reports | Refund-rate monitoring, lost-unit reimbursement |
| Catalog | getCatalogItem, searchCatalogItems | Product enrichment for the seller's own ASINs |
| Reports | requestReport, getReport for: settlement, FBA inventory, sales-and-traffic, restock | Scheduled analytics |
We do NOT request or access:
- Restricted Personally Identifiable Information (PII): buyer name, buyer email, buyer phone, buyer shipping address.
- Tax document data.
- Any SP-API operation outside the scope listed above.
If a future feature requires PII or any other restricted role, we will (a) submit a new Restricted Data Token request to Amazon, (b) update this Plan, (c) update Section 14B of the Privacy Policy, (d) re-prompt connected sellers for explicit consent — in that order.
2. Authorization Model
We implement Amazon's "Self-Authorization for Private Developer Apps" pattern. Each seller creates their own private developer application inside their own Seller Central account and grants us access to it. We do not operate a public OAuth solution-provider listing at this time. Concretely:
- The seller follows the published "Connect Amazon" guide at /docs/connect-amazon.
- The seller pastes their LWA application Client ID, Client Secret, and refresh token into our secure intake form inside the Software.
- Our backend stores those three values only as described in §3.
- The seller can revoke at any time inside Seller Central → Apps & Services → Manage Your Apps; the operation immediately invalidates the refresh token on Amazon's side.
3. Storage, Encryption, and Key Management
Encryption at rest. All Amazon SP-API credentials (LWA Client Secret, refresh token, role ARN for any future restricted-token use) are encrypted with AES-256 before being written to our Supabase Postgres database. They are sealed inside Supabase Vault rows under per-credential row-level security (RLS) policies that scope read access to the row owner's session JWT or the production service role. The encryption keys are managed by Supabase Vault (Postgres pgsodium + KMS-backed root key) and never leave the Vault tenant.
Encryption in transit. TLS 1.2 or higher is enforced on every leg of the data path: browser → our application servers (Vercel, HTTPS only), our application servers → Amazon SP-API (HTTPS), our application servers → Supabase (TLS-only Postgres connection).
No plaintext logging. Application logs flow through a Pino-based redactor at lib/logger.ts that strips refresh tokens, access tokens, LWA secrets, and SP-API authorization headers before serialization. No SP-API credential ever reaches our log aggregation tier in plaintext.
Region. The Supabase database hosting Amazon SP-API credentials and sync'd Amazon data resides in AWS us-east-1. (If we migrate region, we will update this Plan, notify Amazon Developer Compliance, and notify affected sellers under Section 12 of the Privacy Policy.)
4. Access Controls
Internal access scope. Amazon SP-API refresh tokens and the raw API response cache are accessible only via the production Supabase service role and a single named engineering owner account held by AllDayFBA LLC's sole engineering owner. No customer-support agent, marketing team member, contractor, or coach has access. The dashboard role used by AllDayFBA's part-time SaaS operations contractor is scoped to read-only on production and has no permission to read the seller_credentials table, the credential_use_log table, or any Supabase Vault row.
Per-call audit trail. Every load of a credential (loadCredentialContext()) writes an immutable row to credential_use_log recording: timestamp, credential ID, calling service, calling user (if applicable), and operation type. There is no code path that loads a credential without also writing this audit row.
Two-factor authentication. All internal accounts capable of administering production data (Supabase project admin, Vercel project admin, GitHub organization admin) require hardware-key or TOTP second-factor authentication. Password-only sign-in is disabled at the IdP level.
5. Network and Application Security
- The application runs on Vercel's managed Next.js platform; all traffic terminates at Cloudflare with WAF rules enabled.
- Rate limiting is enforced per-IP and per-user on all authenticated routes (
lib/rate-limit.ts) including the SP-API connection intake form. - All write endpoints are CSRF-protected via Supabase Auth's SameSite session cookies and double-submit token validation.
- Zod schemas validate every inbound payload at the route boundary; unknown keys are rejected to defeat property-injection attacks.
- Dependencies are continuously monitored via GitHub's Dependabot; critical-severity advisories are remediated within 48 hours.
6. Retention and Deletion
Refresh tokens. Deleted immediately when the seller hits Settings → Integrations → Disconnect Amazon, the seller revokes our app in Seller Central, or the seller deletes their 24/7 Profits account. The seller_credentials row is updated to status='revoked' and the encrypted secret blob is overwritten to NULL inside Supabase Vault. The cached access token is dropped from the in-process LRU cache.
Sync'd Amazon data. Orders, inventory snapshots, pricing snapshots, and derived analytics derived from SP-API responses are retained per Section 8 of the Privacy Policy so that the seller's historical analytics (refund rates, BSR trends, profit history) survive disconnect-and-reconnect cycles. A seller who wants their derived Amazon data deleted as well exercises full account deletion under Section 9 of the Privacy Policy by emailing privacy@247profits.org. We will purge both credentials and derived data within the 30-day window required by Amazon's Data Protection Policy from the date the deletion request is verified.
Audit logs. credential_use_log rows are retained for 13 months for security review, then truncated.
Backups. Encrypted Supabase point-in-time backups are retained for 7 days (Pro tier). On a successful account-deletion DSAR, the next backup cycle (≤24 hours later) is the last one that may still contain the credential row; after that, the backups also age out within 7 days. We do not run cold-archive backups beyond this window.
7. Breach Response
If we discover or are informed of a security incident affecting Amazon SP-API data we will:
- Within 24 hours of detection: report the incident to Amazon at security@amazon.com, including (to the extent then known) the incident timeline, the categories of Amazon Information involved, the affected seller count, and our initial containment actions.
- Within 24 hours: triage scope, isolate the affected systems (rotate the Supabase service-role JWT, force-revoke all SP-API refresh tokens), and notify the engineering owner.
- Within 72 hours: provide Amazon Developer Compliance, through the Developer Central case channel, a full report with: (a) incident timeline, (b) affected data categories, (c) affected seller count, (d) containment actions, (e) remediation plan.
- In accordance with applicable law: notify affected sellers individually (email of record + in-Software banner) within the statutory window for the seller's jurisdiction.
This protocol is owned by AllDayFBA LLC's engineering owner, defines incident-response roles in §8, is reviewed at least once every six months, and is rehearsed quarterly. The 24-hour notification to security@amazon.com is performed for every confirmed security incident involving Amazon Information regardless of severity.
8. Employee and Contractor Security
We are a small operating team. The full list of personnel with any production access is published in the Subprocessors page at /subprocessors under "AllDayFBA LLC Internal Personnel." Every individual on that list:
- Has a unique IdP account with hardware-key or TOTP second factor.
- Is bound by a written confidentiality agreement that survives the engagement.
- Receives onboarding training on Amazon's Acceptable Use Policy and Data Protection Policy before being granted access.
- Has their access automatically revoked the same business day their engagement ends.
9. Subprocessors
The complete subprocessor list is published at /subprocessors and incorporated here by reference. For the Amazon SP-API data path specifically:
| Subprocessor | Role | Region | Encryption |
|---|---|---|---|
| Supabase, Inc. | Database + Vault + Auth (production primary) | AWS us-east-1 | AES-256 at rest, TLS 1.2+ in transit |
| Vercel, Inc. | Compute (Next.js runtime) | Global edge, primary fly-2 region us-east | TLS 1.2+ in transit; no persistent storage of SP-API data |
| Cloudflare, Inc. | CDN + WAF | Global edge | TLS 1.2+ in transit; no persistent storage of SP-API data |
Amazon SP-API data is not routed through any analytics, marketing, AI training, or ad-tech subprocessor.
10. No-Use Attestations
We attest the following with respect to data accessed via Amazon SP-API, in addition to the affirmative purpose limitation in §1:
- No advertising. Amazon SP-API data is not used to target or retarget any advertising on Amazon, on 24/7 Profits, on any third-party platform, or anywhere else.
- No sale or rental. Amazon SP-API data is not sold, rented, or licensed to any third party.
- No cross-account aggregation. We do not aggregate one seller's Amazon data into a feature visible to another seller without the originating seller's explicit, opt-in consent (and even then only as de-identified competitive benchmarks, never as raw orders or inventory).
- No AI training. Amazon SP-API data is not used to train, fine-tune, or pretrain any machine-learning model. Our AI subprocessors (Anthropic via the Claude API, OpenAI via the GPT-5 API where applicable) are configured for zero-retention API access; their providers contractually agree not to train on our prompts and responses.
- No re-identification. We do not attempt to re-identify buyers, recipients, or third parties from any Amazon-provided data set.
11. Change Management and Version History
This Plan is versioned. Material changes are published with a new version number, a new effective date, and a changelog entry preserved at the head of the document. When this Plan changes, Section 14B of the Privacy Policy is updated in the same commit and connected sellers are notified by email if the change materially affects how their data is processed.
Version history:
- 1.0 (2026-05-25) — initial publication accompanying the Amazon SP-API Developer Application submission.
12. Contact
Security incidents: security@247profits.org Privacy / data deletion: privacy@247profits.org General support: support@247profits.org
AllDayFBA LLC dba 24/7 Profits (Postal address as listed in the footer of every legal page.)