What the orchestration layer does, and what it stops you doing by hand.

One screen for the state of every connection, sync and queue.

What it does

Reports the running state of the orchestration layer: which provider accounts are connected, which entities synced and when, which credentials are close to expiry, and what failed.

What it replaces

The tab-switching round of Shopify admin, Seller Central and QuickBooks that operators do every morning to find out whether last night worked.

What you can see

• Entity counts per provider, with the time of the last successful sync
• Auth diagnostics, including production and sandbox environment mismatch
• Failed runs and the errors that caused them

Limits. Read-only. Actions that change provider state are performed from the connection itself, not from the command center.

One product list across storefronts and marketplaces, matched by SKU.

What it does

Brings Shopify variants and Amazon listings into a single list and matches them across accounts. An ambiguous SKU is surfaced as ambiguous rather than merged into a single row that hides the conflict.

What it replaces

The master spreadsheet that is manually re-exported from each provider and is out of date before it is circulated.

What you can see

• Every SKU with its per-account listing status
• Cross-account match status, including unmatched and ambiguous SKUs
• Which provider account each record came from

Limits. Matching is by SKU through explicit product-map tables. Products with no mapping are reported as unmatched rather than guessed.

One provider integration serving many seller accounts.

What it does

Models the provider, the account and the storefront as three separate things. One Shopify integration serves many shop domains; one Amazon integration serves many marketplaces. Records are scoped to the organization and the connection that produced them.

What it replaces

Running a second instance, a second database or a second subscription for every additional seller account.

What you can see

• Every connection with its provider, account identifier and organization
• Which records belong to which connection
• Credential expiry per connection

Limits. Connections are created through the provider OAuth flow. Bulk import of existing accounts is not available.

Orders from every sales channel in one normalized list.

What it does

Captures orders from connected provider accounts and normalizes them into a shared shape, so an Amazon order and a Shopify order can sit in the same list, filter and total.

What it replaces

Separate order queues per sales channel, and the reconciliation spreadsheet that tries to add them up.

What you can see

• Orders across all connected accounts, filterable by channel and date
• The source record behind every normalized order
• Which provider account and connection each order arrived on

Limits. Order data is read from the providers. Creating or editing orders in a provider from this layer is not available.

Comparable stock pools compared, incomparable pools reported side by side.

What it does

Reconciles stock across accounts with the fulfillment model kept intact. Shopify available and Amazon merchant-fulfilled stock draw on the same physical pool and are differenced. Amazon FBA stock sits inside Amazon's network and is reported alongside, never differenced, because treating it as a discrepancy would flag every FBA SKU.

What it replaces

The stock comparison built by hand in a spreadsheet, which usually differences pools that are not comparable and produces a list of false mismatches.

What you can see

• Per-SKU stock by account, with FBA fulfillable, inbound and reserved shown separately
• A merchant-side delta that is null when there is no comparable counterpart
• A reconciliation status per SKU, including not comparable

Limits. Allocation is not shipped. There is no warehouse inventory table in this system yet, so no warehouse column is shown and no sellable quantity is published back to a sales channel. Today this capability is visibility and reconciliation only.

Scheduled synchronization with a recorded run history.

What it does

Runs incremental synchronization per provider entity and records every run. Failures retry with backoff and land in a dead-letter queue that can be inspected rather than disappearing into a log file.

What it replaces

Cron scripts whose only output is an exit code, and the question "did it run last night" that nobody can answer.

What you can see

• Every sync run with its entity, duration, record counts and outcome
• Dead letters with the payload and the error that produced them
• Data freshness per entity

Limits. Synchronization is scheduled. Inbound webhooks are available for Shopify only, so other providers are as current as their last scheduled run.

Health reported in layers, not as a single green dot.

What it does

Reports connection health as separate signals: credential expiry, webhook lag and per-entity sync state. A connection with valid credentials and a stalled webhook is not the same failure as an expired token, and is not reported as if it were.

What it replaces

A single status indicator that is green until something has already been broken for a day.

What you can see

• Credential expiry per connection
• Webhook lag, where the provider sends webhooks
• Per-entity sync state and last success

Limits. Webhook lag is measured for Shopify, the only provider sending inbound webhooks today. It is reported as unavailable elsewhere rather than as zero.

Turning a failed sync into a tracked incident with an owner.

What it does

Planned. Group related failures into an incident, assign an owner, record what was done and keep the history against the connection.

What it replaces

The screenshot pasted into a group chat, and the fix nobody wrote down.

What you can see

• Not available yet

Limits. Not implemented. Failures today are visible as dead letters and failed runs, which have no owner, state or resolution history.

Contribution margin per sales channel, with its own coverage stated.

What it does

Computes gross sales, cost of goods and marketplace fees per sales channel on an order-date basis, and reports contribution margin together with the share of sales whose cost is actually known.

What it replaces

A margin number typed into a board deck that nobody can trace back to an order.

What you can see

• Contribution margin per sales channel, with gross sales, cost and fees
• Cost coverage as a percentage, so partial cost data is visible rather than assumed
• Whether a fee feed exists for that channel at all

Limits. Margin is per sales channel, not per order. Cost is known only for products mapped to a ledger item; unmapped lines are excluded from cost and counted against coverage rather than treated as free. Shopify has no fee feed in this system, so its fees are absent rather than zero. Both gaps push cost down, which makes the reported margin a ceiling. The figure is dated by order date and is not a cash view.