AtlasCore Market

Oracle NetSuite Commerce Legal addendum · Legal version v1 · Last updated: July 13, 2026

Oracle NetSuite Commerce Data Handling

Last updated: August 25, 2026

AtlasCore is an independent software application. NetSuite, Oracle NetSuite Commerce, and related marks are trademarks of Oracle Corporation or its affiliates. AtlasCore is not sponsored, endorsed, or affiliated with Oracle or NetSuite.

Data accessed

When you connect a NetSuite account, AtlasCore may access:

- Account ID / realm as an operational identifier; Token-Based Authentication Consumer Key/Secret and Token ID/Secret, plus optional webhook secrets (encrypted at rest)

  • Health checks and connection validation evaluate SuiteTalk reachability via a lightweight `salesOrder` list probe. Inventory mutations (`PATCH /services/rest/record/v1/inventoryItem/{id}`) remain unused and run only when `NETSUITE_WRITE_APPROVED=true`
  • Operational order metadata only: internal/tran id, status, totals, dates, and line-item SKU/quantity

AtlasCore does not scrape the NetSuite UI. Cached order blobs store an allowlisted operational subset only. Customer entity records, emails, telephone numbers, billing addresses, shipping addresses, and addressee fields are not persisted.

Seller dashboard reads (`GET /orders/` and `GET /orders/cache/`) return local cache rows only. Live server-side SuiteTalk 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 NetSuite sync worker. SuiteTalk SOAP, RESTlets, and OAuth 2.0 are not used.

Encryption & transport

- TBA Consumer Key/Secret, Token ID/Secret, and optional webhook secrets are stored using AES-256-GCM encryption at rest with the `enc:v1:` format. The realm `account_id` and sandbox/production `environment` label are stored as operational identifiers (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 SuiteTalk REST Record API with per-account OAuth 1.0a Token-Based Authentication. Seller inventory writes run only when both `NETSUITE_INTEGRATION_ENABLED` and `NETSUITE_WRITE_APPROVED` are true. Inbound order webhooks never issue inventory mutations.

Webhook security

Inbound NetSuite notifications at `POST /api/v1/netsuite/webhooks/` are verified using HMAC-SHA256 (`X-NetSuite-Signature`) over the raw request body. A missing or invalid signature returns HTTP 401 immediately, before timestamp freshness (±300s) is evaluated. This is an AtlasCore SuiteScript HMAC contract: merchants deploy SuiteScript (or equivalent middleware) that signs the POST body with a dedicated webhook secret. Oracle NetSuite does not provide a native signed-webhook authenticity header for this ingress. If the platform signing secret does not match, AtlasCore may parse a bounded payload solely to extract `account_id` / realm for per-account key resolution. HMAC is then strictly verified before any data persistence or dispatch. Webhook ingress ignores `X-Tenant` and binds to the verified realm. Unknown realms that present a valid HMAC are acknowledged with `200` so NetSuite does not retry-storm. If the same realm is active in more than one workspace, webhook resolve fail-closes. Connect enforces one active realm globally. TBA token secrets are never used as HMAC material.

Success-path webhook rows store identifiers only (`event_id`, account binding, realm, `order_id`, event type). Thin webhook status patches are non-destructive — they do not wipe allowlisted totals, currency, native dates, or line items. Leftover failed-row ciphertext is scrubbed after 24 hours. Account deauthorization events persist the event id before credentials and cached data are purged. Unlinked `netsuite_processed_webhook_events` rows (event ids only) are retained after disconnect.

Tenant isolation

- NetSuite account 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 NetSuite account data across accounts for comparative insights or public display
  • AtlasCore strictly prohibits re-identification, sale, or unauthorized secondary use of NetSuite seller or buyer data

Retention

AtlasCore redacts cached NetSuite order payloads after 30 days post-fulfillment or 90 days unfulfilled, whichever applies. The 90-day unfulfilled ceiling is anchored to the native SuiteTalk `tranDate` / `createdDate`. Fulfillment clocks start at the first exact terminal order transition (`BILLED`, `CLOSED`, `CANCELED`, `CANCELLED` — Billed / Closed / Cancelled) and are not reset on later syncs. Persistent 401/403 responses fail closed until the merchant reconnects.

Disconnect & deletion

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

  • Webhook idempotency keys in `netsuite_processed_webhook_events` are retained (unlinked, ids only) after credential purge so a later reconnect cannot ingest the same notification twice
  • GDPR export includes all NetSuite tenant bindings per user with `tenant_id`

Contact

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