Skip to main content

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 same external_id updates the row, never duplicates it.
  • tenant_id / workspace_id come 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.
Minimal example payload:
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.

Query it