AtlasCore Market

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

Wish Data Handling

Last updated: August 24, 2026

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

Data accessed

When you connect a Wish merchant account, AtlasCore may access:

- Merchant ID and merchant name as operational identifiers; OAuth access tokens, refresh tokens, and optional webhook secrets (encrypted at rest)

  • Health checks and connection validation evaluate merchant identity and order-list reachability. Product catalog lookups (`GET /product`) are latent unused helpers with no seller-facing route or webhook trigger. Inventory mutations (`POST /product/{id}/update-inventory`) remain unused and run only when `WISH_WRITE_APPROVED=true`
  • Operational order metadata only: order ID, status, totals, currency, dates, and line-item SKU/quantity

AtlasCore does not scrape the Wish Merchant Dashboard. Cached order blobs store an allowlisted operational subset only. Buyer names, phones, emails, and shipping address blocks are not persisted.

Seller dashboard reads (`GET /orders/` and `GET /orders/cache/`) return local cache rows only. Live server-side Wish 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 Wish sync worker.

Encryption & transport

- Merchant OAuth access tokens, refresh tokens, and optional webhook secrets are stored using AES-256-GCM encryption at rest with the `enc:v1:` format. `merchant_id` 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 Wish Merchant API OAuth 2.0 v3 or seller-supplied tokens. Default requested scopes are read-only (`orders:read merchant:read products:read`). Seller inventory writes (`product/{id}/update-inventory`) run only when both `WISH_INTEGRATION_ENABLED` and `WISH_WRITE_APPROVED` are true. A write-capable OAuth grant is not sufficient by itself. Inbound order webhooks never issue inventory mutations.

Webhook security

Inbound Wish notifications at `POST /api/v1/wish/webhooks/` are verified using HMAC-SHA256 (`X-Wish-Signature`) over the raw request body before timestamp freshness is accepted. After HMAC verification, a bounded parse extracts `merchant_id` for account binding. HMAC is authenticity proof; dispatch and deauth bind only when the verified merchant ID matches an active account whose stored secret matched (or the unique active merchant under the platform secret). HMAC is then strictly verified before any data persistence or dispatch. Unknown or ambiguous merchant IDs that present a valid HMAC are acknowledged with `200` so Wish does not retry-storm; the merchant-namespaced event id is recorded on `wish_processed_webhook_events` in unlinked state. Connect enforces one active merchant ID globally.

Success-path webhook rows store identifiers only (`event_id`, account binding, `merchant_id`, `order_id`, event type). Identifier-only replay must not overwrite existing operational caches (totals, currency, native creation timestamps, line items). Leftover failed-row ciphertext is scrubbed after 24 hours. App revocation and merchant deauthorization events persist the event id before credentials and cached data are purged. Unlinked retention after disconnect applies strictly to `wish_processed_webhook_events` — there is no inventory adjustment ledger.

Tenant isolation

- Wish merchant data is isolated per authenticated user and enterprise workspace — connected accounts and settings are bound to the signed-in seller and AtlasCore tenant via the `X-Tenant` header

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

Retention

AtlasCore redacts cached Wish order payloads after 30 days post-fulfillment or 90 days unfulfilled, whichever applies. The 90-day open ceiling uses native Wish order time (`created_at` / `create_time`). Fulfillment clocks start at the first terminal order transition (`SHIPPED` / `DELIVERED` / `CANCELLED` / `CANCELED` / `REFUNDED` / `FULFILLED` / `COMPLETED` / `COMPLETE` / `CLOSED`) and are not reset on later syncs.

Disconnect & deletion

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

  • Replay defense identifiers on `wish_processed_webhook_events` are retained in unlinked state after credential purge so a later reconnect cannot ingest the same notification twice. Unlinked retention does not apply to an inventory adjustment ledger
  • GDPR export includes all Wish tenant bindings per user with `tenant_id`

Contact

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