Data and Compliance

This page describes how AutoFBA hosts, encrypts, isolates, and audits the data you entrust to us. It complements our Privacy Policy (which explains what data we collect and why) by describing the technical and organisational measures we use to protect it.

We design AutoFBA to meet the requirements of the Amazon Selling Partner API Data Protection Policy, the EU General Data Protection Regulation (GDPR), the UK GDPR, and the California Consumer Privacy Act (CCPA / CPRA). We are not yet SOC 2 or ISO 27001 certified; we will update this page as our compliance posture matures.

AutoFBA is hosted on Vercel (application layer) and Supabase (database, authentication, and file storage). Primary data stores are located in the United States. Edge functions and static assets are served from Vercel’s global edge network; only request metadata (not stored personal data) transits edge regions.

We do not currently offer an EU- or UK-residency tier. If your regulatory situation requires it, contact security@autofba.ai before subscribing.

3.1 In transit

All connections to AutoFBA require HTTPS using TLS 1.2 or higher with modern cipher suites. Cookies are issued withSecure and HttpOnly attributes. API tokens and webhook secrets are transmitted only over TLS.

3.2 At rest

The Postgres database, file storage, and database backups are encrypted at rest using AES-256 by our infrastructure providers. PII fields including customer names and shipping addresses are additionally encrypted at the application layer before being written to the database.

3.3 Secrets

API keys, OAuth refresh tokens, the Stripe webhook secret, and third-party credentials are stored in Vercel’s encrypted environment-variable store. They are never written to logs, source control, or client-side bundles.

4.1 Row-Level Security

Every user-scoped table in the Postgres database has Row-Level Security (RLS) policies that restrict reads and writes to rows owned by the authenticated user. Cross-user access is blocked at the database layer, not only the application layer, so a bug in the application cannot leak another customer’s rows.

4.2 Admin access

Production database access is restricted to a small number of authorised engineers and requires multi-factor authentication. Administrative operations are performed via service-role connections that bypass RLS only where required (cron jobs, webhook handlers, billing reconciliation) and are logged.

4.3 Least privilege

Application code uses scoped credentials per service: the anon-key client (limited by RLS) for end-user requests, and the service-role client only for explicit administrative paths. OAuth refresh tokens for Amazon SP-API are scoped to the minimum permissions you grant at connect time.

We log request paths, response status codes, latency, and error stack traces for operational monitoring. We deliberately do not log:

• full request or response bodies on routes that carry PII;
• customer names, shipping addresses, or other buyer-identifiable data;
• payment card numbers, CVVs, or bank account details (Stripe handles these);
• OAuth tokens, API keys, or other secrets.

Administrative actions on production data are recorded in an audit trail. Database backups are retained per Supabase’s policy for the project tier and are also encrypted at rest.

We use the following sub-processors. Each operates under a data protection agreement and is contractually required to protect your data to standards no lower than ours:

• Supabase (USA) — authentication, database, file storage
• Vercel (USA) — application hosting and edge delivery
• Stripe (USA) — payment processing and subscription billing
• Amazon Web Services (via Supabase & Vercel) — underlying compute and storage
• OpenAI (USA) — AI inference for listing copy, product matching, supplier drafts
• Anthropic (USA) — AI inference for evaluation and complex reasoning
• Resend (USA) — transactional email delivery
• Upstash (USA / global) — rate limiting and short-lived caching
• Inngest (USA) — durable background-job orchestration

We will give you at least 30 days’ notice of any new sub-processor that processes personal data, by updating this page and (for paying customers) by email.

AutoFBA is an Amazon Selling Partner API developer. We commit to the Amazon SP-API Data Protection Policy and its supporting requirements:

• We use only official SP-API endpoints — we never scrape Amazon HTML.
• Personally Identifiable Information (PII) we receive from Amazon (e.g. buyer shipping addresses for FBM order labels) is encrypted at rest, is never logged, and is retained only for as long as required to perform the function you authorised or as required by the SP-API Data Protection Policy.
• Access to PII fields is gated by RLS and limited to the minimum application paths that need it.
• We honour the data-deletion windows required by Amazon when an order is cancelled or a connection is revoked.
• If you disconnect a Seller account, we stop pulling new data immediately and delete or anonymise stored PII for that account within the timeframe required by the SP-API Data Protection Policy.

AutoFBA does not store, process, or transmit raw cardholder data. All payment-card information is collected and handled by Stripe under Stripe’s PCI DSS Level 1 attestation. Our servers only see the resulting Stripe customer identifier and subscription status.

If you are located in the European Economic Area, the United Kingdom, California, or another jurisdiction that grants data-subject rights, you may request to:

• access the personal data we hold about you;
• correct inaccurate personal data;
• delete your account and associated personal data;
• receive a copy of your data in a portable format;
• restrict or object to certain processing;
• opt out of any “sale” or “sharing” of personal data (we do neither).

Submit data-subject requests to privacy@autofba.ai. We will verify your identity and respond within the period required by applicable law (typically 30 days, extendable in complex cases).

When personal data of EU, EEA, or UK individuals is transferred to the United States or to other countries that do not have an adequacy decision, we rely on the European Commission’s Standard Contractual Clauses (SCCs) and the UK International Data Transfer Addendum, supplemented by the technical and organisational measures described on this page.

We maintain an incident response process that covers detection, containment, eradication, recovery, and post-incident review. If we discover a security incident that involves your personal data we will:

• notify affected customers without undue delay, and in any event within 72 hours of becoming aware where required by law;
• notify the relevant supervisory authorities within the timeframe required by GDPR / UK GDPR / state breach laws;
• provide a description of the incident, the categories of data affected, the likely consequences, and the measures taken or proposed to address it.

Report a suspected vulnerability or security incident to security@autofba.ai. We acknowledge reports within two business days.

The production database is backed up daily by Supabase, with encrypted backups retained per the project tier. We test restore procedures periodically. Application code is version controlled and reproducible; infrastructure is described in code and can be re-provisioned on alternative providers if required.

Paying customers can subscribe to compliance-update emails (toggle in Account > Notifications) to be notified when this page changes materially, when a sub-processor is added or removed, or when an incident-disclosure update is published.

Security reports & vulnerability disclosure: security@autofba.ai

Privacy and data-subject requests: privacy@autofba.ai