What it is
E-commerce orders with status tracking. One row per order, sourced from your shop system (Shopify in the standard setup —external_id is the Shopify Order gid). Orders carry payment state (financial_status), shipping state (fulfillment_status), totals, and full billing/shipping address blocks. Line-level detail lives in Order Line Items, linked via order_external_id.
Orders are the raw material for the demand and retention analytics: Product Demand, Weekly Sales, and Customer Reorder Due are all computed from them. A sale counts when financial_status is not refunded/expired/voided, and it counts on placed_at — never on the sync date.
How it gets data
Ingest-enabled — external systems push rows through the Ingest API:- One JSON record per request. Only registered columns are accepted; unknown fields are dropped.
- Idempotent upsert on
(tenant_id, external_id)— re-sending the sameexternal_idupdates the row, never duplicates it. tenant_id/workspace_idcome from the API key context, never from the body.- A ready-made Make.com flow template for Shopify → orders is downloadable in Settings → Data Sources.
Demand analytics filter on
financial_status (refunded/expired/voided orders don’t count as sales) and date on placed_at — send both. The legacy status column is no longer populated by modern Shopify syncs; keep sending fulfillment updates so paid-but-unshipped tracking stays accurate.Fields
Identity & status
Money & customer
Shipping address
Billing address
“ingest” = populated through the ingest endpoint; read-only in the app and over MCP row writes.
metadata is accepted on ingest but not surfaced as a default table column.
Like every workspace table, orders also carry the system columns
id (internal row id), tenant_id, workspace_id (tenant isolation — stamped from the API key), and created_at (row creation). Never send them; they are managed automatically.