Squarespace Commerce Legal addendum · Legal version v1 · Last updated: July 13, 2026
Squarespace Data Handling
Last updated: August 24, 2026
AtlasCore is an independent software application. Squarespace and related marks are trademarks of Squarespace, Inc. or its affiliates. AtlasCore is not sponsored, endorsed, or affiliated with Squarespace.
Data accessed
When you connect a Squarespace Commerce store, AtlasCore may access:
- Site identifier and Commerce API key or OAuth access/refresh tokens (encrypted at rest)
- Optional per-store webhook signing secret (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 Squarespace 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 Squarespace fetches run only on `POST /sync/`.
Encryption & transport
- Commerce API keys and OAuth tokens 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 supports merchant-provided Commerce API keys and OAuth PKCE. Requested OAuth scopes are least-privilege:
- Read-only installs (`SQUARESPACE_WRITE_APPROVED` unset/false): `website.orders.read,website.products.read`
- Write-approved installs (`SQUARESPACE_WRITE_APPROVED=true`): `website.orders,website.products,website.inventory`
Seller writes (inventory adjustments and order fulfillments) run only when both `SQUARESPACE_INTEGRATION_ENABLED` and `SQUARESPACE_WRITE_APPROVED` are true. A write-capable merchant key or OAuth grant is not sufficient by itself. Inbound order webhooks never issue stock PUTs — Squarespace already decrements managed inventory when an order is placed.
Webhook security
Inbound Squarespace notifications at `POST /api/v1/squarespace/webhooks/` are verified using hex HMAC-SHA256 over the raw request body. Official `Squarespace-Signature` is accepted; `X-Squarespace-Signature` remains an alias.
Primary replay defense is the durable notification-id ledger plus HMAC body verification. Official Squarespace deliveries do not send a timestamp header (`createdOn` is in the JSON body). `X-Squarespace-Timestamp` is an optional/inert freshness check only if present. A timestamp is not required for acceptance.
When a global `SQUARESPACE_WEBHOOK_SECRET` does not match, AtlasCore parses the incoming JSON envelope in memory to extract `websiteId`, then uses that identifier to select the per-store secret and verifies HMAC before persist. The envelope is not stored until signature verification succeeds. Unknown site identifiers that present a valid HMAC are acknowledged with `200` so Squarespace does not retry-storm. If the same `site_id` is active in more than one workspace, webhook resolve fail-closes. Connect enforces one active site globally.
Success-path webhook rows store identifiers only (`event_id`, site binding, `order_id`, topic). Leftover failed-row ciphertext is scrubbed after 24 hours.
Tenant isolation
- Squarespace account 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
- Unified channel-order rows are scoped to the seller; ambiguous cross-workspace matches are skipped rather than redacted as a merge
- AtlasCore never aggregates Squarespace store data across sellers for comparative insights or public display
- AtlasCore strictly prohibits re-identification, sale, or unauthorized secondary use of Squarespace store or buyer data
Retention
AtlasCore redacts cached Squarespace 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 the exact terminal set `FULFILLED`, `CANCELED`, `CANCELLED`, `SHIPPED`, `DELIVERED`, `COMPLETED`, `CLOSED`, using `fulfilledOn` (or first terminal time when `fulfilledOn` is absent). `PENDING` and other non-terminal statuses, including `PAID`, remain under the 90-day open ceiling measured from native `createdOn`. Fulfillment clocks are not reset by later syncs.
Disconnect & deletion
- Disconnect Squarespace from the dashboard purges encrypted credentials, cached orders/products, and OAuth state for your tenant
- Webhook replay defense identifiers in `squarespace_processed_webhook_events` are retained after credential purge (account binding cleared) so a later reconnect cannot ingest the same notification twice
- `extension.uninstall` persists the notification, then purges credentials for that site
- GDPR export includes Squarespace tenant bindings per user with `tenant_id` (site id and order counts — not raw order JSON)
Contact
For data handling questions: privacy@atlascore-market.com