AtlasCore Market

BigCommerce Legal addendum · Legal version v1 · Last updated: July 13, 2026

BigCommerce Data Handling

Last updated: August 24, 2026

AtlasCore is an independent software application. BigCommerce and related marks are trademarks of BigCommerce Pty. Ltd. AtlasCore is not sponsored, endorsed, or affiliated with BigCommerce.

Data accessed

When you connect a BigCommerce store, AtlasCore may access:

- Store hash, store name, and OAuth access token (encrypted at rest)

  • Product catalog metadata (title, SKU, price, stock quantity, visibility)
  • Operational order metadata only: order id, status, totals, currency, dates, and line-item SKU/quantity

AtlasCore does not scrape BigCommerce admin surfaces. Cached order blobs store an allowlisted operational subset only. Billing/shipping name, address, email, phone, and customer fields are not persisted.

Seller-facing `GET /orders/` and `GET /products/` return local cache rows only. Live BigCommerce fetches run only on `POST /sync/` (and catalog/inventory sync POSTs).

Encryption & transport

- Store access tokens are stored using AES-256-GCM encryption at rest with the `enc:v1:` format. BigCommerce store tokens do not use a refresh-token grant.

  • Cached order payloads are encrypted at rest and redacted per retention policy
  • Production API traffic uses TLS 1.2+ (HTTPS)

Authentication

AtlasCore supports OAuth authorization code (Single-Click App or dashboard start) and merchant-pasted store access tokens. Requested OAuth scopes are read-only `store_v2_orders_read_only store_v2_products_read_only` unless `BIGCOMMERCE_WRITE_APPROVED` is true, in which case AtlasCore requests `store_products store_orders store_inventory`. Catalog and order reads run when the integration is enabled. Seller writes (product create, stock/price updates, order status) run only when both `BIGCOMMERCE_INTEGRATION_ENABLED` and `BIGCOMMERCE_WRITE_APPROVED` are true. A write-capable OAuth grant is not sufficient by itself. Inbound order webhooks never issue stock PUTs — BigCommerce already decrements managed inventory when an order is placed.

Webhook security

Inbound BigCommerce notifications at `POST /api/v1/bigcommerce/webhooks/` are verified using hex HMAC-SHA256 (`X-BC-Signature`) over the raw request body before JSON parsing. `created_at` freshness (±300s) is required after parse. Unknown store hashes that present a valid HMAC are acknowledged with `200` so BigCommerce does not retry-storm. If the same `store_hash` is active in more than one workspace, webhook resolve fail-closes. Connect enforces one active store hash globally.

Success-path webhook rows store identifiers only (`event_id` namespaced as `{store_hash}:{delivery_key}`, account binding, `order_id`, scope). Leftover failed-row ciphertext is scrubbed after 24 hours.

Single-Click App lifecycle

AtlasCore implements BigCommerce Single-Click App endpoints (`/auth`, `/load`, `/uninstall`, `/remove_user`) with signed_payload HMAC-SHA256 verification. Uninstall purges cached store data and credentials while the store row is still resolvable (including inactive retry). Replay defense identifiers in `bigcommerce_processed_webhook_events` are retained in an unlinked state so a later reconnect cannot ingest the same notification twice.

Tenant isolation

- BigCommerce accounts, settings, and product mappings are isolated per enterprise workspace via the `X-Tenant` header (personal rows may have a null tenant)

  • Order, product, and status queries are scoped to the authenticated seller within the active workspace
  • Unified `ChannelOrder` snapshots are seller-scoped (`user_id` + channel + external order id), not tenant-partitioned; ambiguous cross-workspace matches are cleared rather than merged
  • AtlasCore never aggregates BigCommerce store data across sellers for comparative insights or public display

Retention

AtlasCore redacts cached BigCommerce channel-order payloads after 30 days post-fulfillment or 90 days unfulfilled, whichever applies. The 30-day clock applies only to canonical status IDs `2` (Shipped), `4` (Refunded), `5` (Cancelled), `6` (Declined), and `10` (Completed), using `date_shipped` or the first terminal time. Status IDs `3` (Partially Shipped) and `7` (Awaiting Payment), plus `Awaiting Fulfillment` and `Awaiting Shipment`, remain under the 90-day open ceiling measured from native `date_created` / `date_created_rfc2822`. Sync does not reset fulfillment clocks.

Disconnect & deletion

- Disconnect BigCommerce from the dashboard purges encrypted credentials, cached orders/products, and OAuth state for your tenant workspace

  • Replay defense identifiers in `bigcommerce_processed_webhook_events` are retained in an unlinked state after credential purge
  • GDPR export includes all BigCommerce tenant bindings per user with `tenant_id`

Contact

For data handling questions: privacy@atlascore-market.com