AtlasCore Market

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

WooCommerce Data Handling

Last updated: August 24, 2026

AtlasCore is an independent software application. WooCommerce and related marks are trademarks of Automattic Inc. and its affiliates. AtlasCore is not sponsored, endorsed, or affiliated with WooCommerce.

Data accessed

When you connect a WooCommerce store, AtlasCore may access:

- Store URL and REST API consumer key/secret (encrypted at rest)

  • Optional per-store webhook signing secret (encrypted at rest)
  • Product catalog metadata (title, SKU, price, stock quantity, status)
  • Operational order metadata only: order id, status, totals, currency, dates, and line-item SKU/quantity

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

Encryption & transport

- REST API consumer keys and secrets are stored using AES-256-GCM encryption at rest with the `enc:v1:` format

  • Optional webhook signing secrets use the same encryption standard
  • Cached order payloads are encrypted at rest and redacted per retention policy
  • Production API traffic uses TLS 1.2+ (HTTPS)

Authentication

AtlasCore connects with merchant-provided WooCommerce REST API keys only. There is no WooCommerce OAuth flow. Platform `WOOCOMMERCE_CONSUMER_KEY` / `SECRET` environment variables are unused and deprecated.

Seller writes (create product, stock/price update, mark order complete) run only when both `WOOCOMMERCE_INTEGRATION_ENABLED` and `WOOCOMMERCE_WRITE_APPROVED` are true. A write-capable merchant key is not sufficient by itself. Merchants who enable writes should create a Read/Write REST key; read-only keys remain sufficient for catalog/order pull when writes are off.

Webhook security

Inbound WooCommerce notifications at `POST /api/v1/woocommerce/webhooks/` are verified using Base64 HMAC-SHA256 (`X-WC-Webhook-Signature`) over the raw request body before JSON parsing for linked stores. Official Woo headers (Topic, Resource, Event, Signature, Delivery-ID, Source) are accepted.

Primary replay defense is the durable delivery-id ledger plus HMAC body verification. Ledger keys are `{store_url_hash}:{delivery_id}` (never the subscription `X-WC-Webhook-ID`, and not scoped by AtlasCore `store_id`, so a reconnect cannot replay the same Woo delivery). Official WooCommerce deliveries do not send `X-WC-Webhook-Timestamp`; that header is an optional/inert freshness check only if WooCommerce provides it upstream. A timestamp is not required for acceptance.

Initial `webhook.ping` deliveries receive an immediate unsigned `200 OK` handshake (no body persist). Unknown store URLs that present a valid global `WOOCOMMERCE_WEBHOOK_SECRET` are acknowledged with `200` so WooCommerce does not auto-disable subscriptions. Linked stores without a per-store webhook secret receive `503`.

If the same normalized store URL is active in more than one workspace, webhook resolve fail-closes (no store is bound). Connect enforces one active store URL globally.

Tenant isolation

- WooCommerce store rows are unique per seller + optional enterprise workspace (`X-Tenant` when present; personal mode uses `tenant_id=null`)

  • Order, product, and status queries are scoped to the authenticated seller within the active workspace
  • Catalog snapshots and unified channel-order rows are scoped to the connected store / workspace; ambiguous cross-workspace matches are redacted rather than merged
  • AtlasCore never aggregates WooCommerce store data across sellers for comparative insights or public display
  • AtlasCore strictly prohibits re-identification, sale, or unauthorized secondary use of WooCommerce store or buyer data

Retention

AtlasCore redacts cached WooCommerce order JSON and linked channel-order payloads after 30 days post-fulfillment or 90 days unfulfilled, whichever applies. The 30-day clock applies only to exact statuses `completed`, `refunded`, `cancelled`, `canceled`, `failed`, `trash`, and `fulfilled`. Statuses `processing`, `on-hold`, and `pending` remain on the 90-day open-order ceiling, calculated from the WooCommerce order creation timestamp (`date_created` / `date_created_gmt`). Webhook ledger ciphertext, if present on a failed row, is scrubbed after 24 hours. Success-path webhook rows store identifiers only (`event_id`, store binding, `order_id`, topic).

Disconnect & deletion

- Disconnect WooCommerce from the dashboard purges encrypted credentials, cached orders/products, and workspace catalog rows for your tenant

  • Webhook idempotency keys are retained after credential purge so a later reconnect cannot ingest the same Woo delivery twice. Inbound order webhooks do not issue stock PUTs (WooCommerce natively manages stock on status transitions)
  • GDPR export includes WooCommerce tenant bindings per user with `tenant_id` (store URL and order counts — not raw order JSON)

Contact

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