Connect, synchronize, monitor, protect, and troubleshoot.

AtlasCommerce requires an eligible organization and workspace. Connecting a store is a privileged mutation: the actor must have the AtlasCommerce entitlement and be an organization/workspace owner or admin.

WooCommerce prerequisites

1. Use an HTTPS WooCommerce store with the REST API available.
2. Create a WooCommerce REST API key for a trusted service account.
3. Select Read permissions. The MVP does not need write access to products, orders, customers, or inventory.
4. Copy the Consumer Key and Consumer Secret once. Treat both as secrets.
5. In AtlasCommerce, select the organization/workspace, enter a clear store name, HTTPS store URL, three-letter currency, Consumer Key, and Consumer Secret.
6. Choose Register and sync WooCommerce. AtlasCommerce first requests a bounded product page to validate the endpoint and credentials. It saves the credentials only after validation, encrypted and service-only.

Required AtlasLoopOS permissions

Other providers

Shopify and Magento / Adobe Commerce are executable catalogue providers in the current Beta. Shopify uses application OAuth; Magento uses four merchant-created OAuth 1.0a integration credentials. The stock-to-signal-to-campaign workflow documented below is hardened first for WooCommerce and does not claim provider parity yet.

1. Successful WooCommerce registration starts an immediate full synchronization.
2. AtlasCommerce reads bounded product pages and detailed variations, then normalizes stable product identity, SKU, name, descriptions, type, status, price/currency, stock state/quantity, categories, images, variants, and provider timestamps.
3. Products are upserted idempotently by connected store plus external product ID. Repeating a sync updates evidence instead of creating duplicate canonical products.
4. Owners/admins can choose Sync now for an explicit full reconciliation. A shared six-hour workflow performs scheduled reconciliation when the deployment scheduler is enabled.
5. Review the synchronization result and history. Successful, partial, and failed runs retain counts and safe errors separately from credentials.

Intentional states

• Loading: the workflow announces that stores, catalogue, or history are being loaded.
• Empty: no store, no product, or no history is represented explicitly rather than as a blank screen.
• Error: credential, endpoint, provider, or API failures are displayed as safe operator-readable messages.
• Retry: correct the configuration, use the relevant retry/refresh control, or run the sync again. Failed evidence is retained; a retry creates new run evidence.

The hardened WooCommerce workflow uses a deterministic product-level threshold. The default is 5 units. A workspace owner/admin may set any integer from 0 to 1,000,000.

• A known quantity at or below the threshold opens one tenant-scoped low_stock inventory event per canonical product.
• A later material observation updates that open event rather than creating duplicates.
• Recovery above the threshold resolves the same event. Explicit provider backorders remain buyable.
• Draft, archived, out-of-stock, missing-from-completed-full-pull, and zero-quantity products remain unavailable under the provider-neutral eligibility policy.
• Low/unavailable stock creates or refreshes one canonical AtlasSignals record with source atlascommerce. Recovery resolves that same signal.

Change the threshold

1. Select the WooCommerce store in the MVP workflow assurance panel.
2. Enter the threshold and choose Save threshold and recompute.
3. The service validates owner/admin access, updates the store policy, appends audit evidence, and recomputes inventory events, AtlasSignals, and campaign state in the same database transaction.
4. Review open events and signals. A failed update shows an explicit error and can be retried without changing prior evidence.

Every normalized commerce product is projected to the existing AtlasCampaigns product content source. The provider-neutral eligibility engine records one of:

• eligible
• ineligible_low_stock
• ineligible_unavailable

The first complete WooCommerce path additionally records an explicit buyable flag, operator-readable reason, update time, and inventory-event lineage on the product source and active linked drafts.

• New product-linked ideas, drafts, schedules, queue execution, and X publishing fail closed while the source is ineligible.
• Draft/approved/scheduled records receive the current buyability projection.
• Human approval, copy, already-published/failed history, and external provider IDs are never rewritten.
• Recovery restores eligibility for future actions but does not silently requeue or republish failed work.

Store, credential, connectivity, synchronization, inventory-event, threshold, eligibility, and buyability transitions append safe rows to the existing platform audit log. The authenticated workflow endpoint first verifies workspace membership, scopes the database query to the selected organization, then returns only events whose details match the selected workspace/store.

Audit details contain IDs, state transitions, quantities, thresholds, safe reasons, run/event lineage, and timestamps. They do not contain Consumer Secrets, OAuth tokens, ciphertext, raw webhook bodies, or customer/order payloads.

Known Beta limitations

• Live merchant-store and PostgreSQL migration proof, large-catalogue load, race handling, outage recovery, browser E2E, and accessibility remain release gates.
• Location safety stock, reservations, bundles, advanced salability, forecasts, reorder recommendations, and autonomous optimization are deferred.
• Orders, customers, fulfillment, checkout, remote write-back, advanced feeds, and complete markets/channels/location mastering are deferred.
• Shopify/Magento catalogue connectors exist, but exact low-stock event and campaign-buyability parity remains deferred.