AtlasCore Market

Magento / Adobe Commerce Legal addendum · Legal version v1 · Last updated: July 13, 2026

Magento / Adobe Commerce Data Handling

Last updated: August 24, 2026

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

Data accessed

When you connect a Magento or Adobe Commerce store, AtlasCore may access:

- Store base URL as an operational identifier; integration access token and optional webhook secrets (encrypted at rest)

  • Health checks and connection validation evaluate store reachability via a lightweight order-list probe. Inventory mutations (`PUT /rest/V1/products/{sku}/stockItems/1`) remain unused and run only when `MAGENTO_WRITE_APPROVED=true`
  • Operational order metadata only: entity/increment id, status, totals, dates, and line-item SKU/quantity

AtlasCore does not scrape the Magento Admin panel. Cached order blobs store an allowlisted operational subset only. Customer names, emails, telephone numbers, billing addresses, and shipping assignment addresses are not persisted.

Seller dashboard reads (`GET /orders/` and `GET /orders/cache/`) return local cache rows only. Live server-side Magento reads run strictly for seller-initiated sync (`POST /sync/`), `GET /status/` health probes, and credential validation at connect — not for seller dashboard order lists. There is no background scheduled Magento sync worker. GraphQL is not used.

Encryption & transport

- Integration tokens, store URLs, and optional webhook secrets are stored using AES-256-GCM encryption at rest with the `enc:v1:` format. A SHA-256 `store_hash` is stored as an operational identifier (not encrypted)

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

Authentication

AtlasCore uses Magento REST API v1. Integration Bearer tokens are the standard authentication mechanism. Optional admin username/password exchange generates a session-scoped Magento admin token (store-configured lifetime); AtlasCore stores only the resulting Bearer token encrypted and does not retain the admin username or password. Seller inventory writes run only when both `MAGENTO_INTEGRATION_ENABLED` and `MAGENTO_WRITE_APPROVED` are true. Inbound order webhooks never issue inventory mutations.

Webhook security

Inbound Magento notifications at `POST /api/v1/magento/webhooks/` are verified using the AtlasCore HMAC-SHA256 header standard (`X-Magento-Signature`) over the raw request body before timestamp freshness (±300s) is evaluated. This is an AtlasCore signing convention for merchant-configured notifications, not an Adobe-native webhook authenticity scheme. Merchant webhook secrets are authenticity checks over those same raw bytes; dispatch and deauthorization bind only to the verified Magento account whose store ID matches the verified payload. A bounded payload is parsed only after HMAC authenticity succeeds. `X-Tenant` is ignored on webhook ingress. HMAC is strictly verified before any data persistence or dispatch. Unknown stores that present a valid HMAC are acknowledged with `200` so Magento does not retry-storm. If the same store is active in more than one workspace, webhook resolve fail-closes. Connect enforces one active store hash globally. Integration bearer tokens are never used as HMAC material.

Success-path webhook rows store identifiers only (`event_id`, account binding, `store_hash`, `order_id`, topic). Leftover failed-row ciphertext is scrubbed after 24 hours. Store deauthorization events persist the event id before credentials and cached data are purged.

Tenant isolation

- Magento store data is isolated per enterprise workspace — each connected account is bound to an AtlasCore tenant via the `X-Tenant` header

  • Order and status queries are scoped to the authenticated seller within the active workspace
  • AtlasCore never aggregates Magento store data across accounts for comparative insights or public display
  • AtlasCore strictly prohibits re-identification, sale, or unauthorized secondary use of Magento seller or buyer data

Retention

AtlasCore redacts cached Magento order payloads after 30 days post-fulfillment or 90 days unfulfilled, whichever applies. Retention applies to Magento order cache rows (and any leftover unified Magento channel-order snapshots). The 90-day unfulfilled ceiling is anchored to native Magento order `created_at`. Fulfillment clocks start at the first exact case-insensitive terminal order transition (`COMPLETE`, `CLOSED`, `CANCELED`, `CANCELLED`) and are not reset on later syncs. Magento `holded` orders remain on the 90-day unfulfilled clock.

Disconnect & deletion

- Disconnect Magento from the dashboard purges encrypted credentials and cached orders for your tenant workspace

  • Unlinked retention after credential purge applies strictly to `magento_processed_webhook_events` (replay defense identifiers and ledger history; no inventory adjustment ledger) so a later reconnect cannot ingest the same notification twice
  • GDPR export includes all Magento tenant bindings per user with `tenant_id`

Contact

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