Skip to main content

Get Sales Order Details

GET 

/api/sales-orders/:salesOrder

Returns the complete order graph for a single sales order: header fields, line items with inventory and cost-of-goods breakdowns, fulfillments (with shipment lines and tracking), payments, notes, financial lines, discounts, addresses, linked purchase orders, and backorder coverage dates.

Required scope: orders:read

Grant this scope to your token under Settings → Developer → Personal Access Tokens.

This is the full detail endpoint. For a lighter order summary, use GET /api/v2/sales-orders/{id} instead.

Authentication: Requires Bearer token.

Response notes:

  • item_info contains the order lines, each with allocation/fulfillment quantities, product info, warehouse, per-warehouse inventory, and a cogs object aggregating the inventory cost layers consumed by the line.
  • fulfillment contains the order's shipments, each with its shipment lines, tracking, warehouse, and provider sync timestamps.
  • sales_order_shipping_address / sales_order_billing_address are the order's own address snapshots (they survive later edits to the underlying address records).
  • customer_name, customer_email, customer_company, customer_phone render the order's buyer snapshot; channel orders without a stored customer record still populate these. customer_name is an object: name is the snapshot name and id is the linked customer's id (null only when the order has no customer record, as with Amazon orders).
  • Monetary totals (total, product_total, tax_total, discount_total, etc.) are in the order currency.
  • routing_provenance is present only when a published order-routing workflow chose this order's warehouse; it is null otherwise. It reports the workflow (workflow_id, workflow_name), the run that made the decision (execution_id), and the warehouse the workflow selected (warehouse_id). The ids are recorded at routing time and are not foreign keys, so workflow_name comes back null once the workflow itself is deleted while the ids remain. A warehouse_id that differs from the order lines' current warehouse means the workflow's choice was later overridden.

Path parameters:

  • salesOrder (required): Sales order ID.

Marketplace fee provenance — fee_source reports where this order's marketplace fee came from, or why there isn't one, so an empty cost-line list is never mistaken for a fee-free order. state is one of actual (the channel reported a settled fee), estimated (a configured rate stands in for one), pending (an estimate is in force while the channel has yet to settle), none (the channel has no fee source configured, so profit on this order is overstated), or unsupported (the channel charges no marketplace fee). Each entry in financial_lines carries fee_basis_source — actual or estimated for a channel-fee line, null for any other line — plus external_source_type / external_source_id naming the settlement record a line was derived from.

Request​

Responses​

OK

Response Headers
    Content-Type