Retrieve a single order by UUID or order_number
Returns a single order (quote, sales order, invoice, or purchase order) by UUID or
order_number. Shopify-style polymorphic path: pass either the UUID id field OR the
human-readable order_number (e.g. SO-001234, INV-0042) as the {id} path segment.
UUID lookup is direct; order_number lookup resolves within the entity scope (Layer 1).
Supports ?expand[]= for line_items, customer, payments, fulfillments,
returns, and timeline. Returns 404 if no matching order belongs to the entity.
Document type is indicated by the document_type field on the response object.
Requires orders:read scope.
Authorizations
API key issued per entity via Settings > Developers > API Keys.
Each key carries scopes (e.g. orders:read, products:write).
Bearer token format: Authorization: Bearer ark_live_ent_Test keys use ark_test_ent_. Both are issued per entity
via Settings > Developers > API Keys.
Path Parameters
The order's UUID id or its human-readable order_number (e.g. SO-001234,
INV-0042, Q-2026-0099). UUID lookup uses a direct index and is slightly faster.
order_number lookup resolves within the authenticated entity scope
(Layer 1 enforced -- cross-entity collision impossible).
Query Parameters
Hydrate related resources inline. Single-resource endpoints do NOT use the
data. prefix (e.g. expand[]=customer). Valid paths: see x-arcus-expand below.
customer, account, line_items, line_items.product, payments, refunds, packages, fulfillments, gl_entries, invoice, tax_lines Response
Order object
An Arcus ERP order document. One table holds quotes, sales_orders, invoices, returns, and purchase_orders -- always filter by document_type. entity_id is always from the API key (Layer 1 isolation).
order quote, sales_order, invoice, return, purchase_order draft, confirmed, partially_fulfilled, fulfilled, cancelled, voided, awaiting_ach_clearance, on_hold unpaid, partially_paid, paid, overpaid, refunded, partially_refunded, voided unfulfilled, partially_fulfilled, fulfilled Derived (display-only): SUM(list_price * qty) over non-kit lines. The gross baseline of the gross-to-net bridge (List price minus pricing_savings equals subtotal). Never part of order_total.
Derived (display-only): SUM(pricing_rule_adjustment * qty) over non-kit lines (positive magnitude). Per-unit pricing-rule savings already baked into subtotal via sell_rate (ASC 606 transaction price); shown as an informational List-to-Subtotal bridge, never subtracted from order_total.
SSOT: utils/ar-helpers.mjs::updateARBalance. Do not write directly.
AR receivable (the amount this document is owed AS A RECEIVABLE). Forced to 0 on DRAFT sales documents, on cancelled / archived / expired orders, and on voided or fully-refunded invoices, because none of those carries a receivable: a draft is not a receivable, and a terminal document owes nothing. This is the number that ties to AR aging, the AR outstanding total, and the GL AR control account. For the amount still COLLECTIBLE on any document at any status (including a draft), use amount_due. Purchase orders and quotes are never forced to 0. SSOT: utils/ar-helpers.mjs::updateARBalance. Do not write directly.
Collectible remainder: order_total minus amount_paid, rounded to 2 decimals. Status-blind BY DESIGN, so it answers "how much is still OUTSTANDING on this document as simple arithmetic" even where balance_due is 0 because the document is not (yet) a receivable. Negative when the customer has overpaid (money owed back to them). On a confirmed, non-refunded document with no sales allowance and no cancellation, amount_due and balance_due are equal. NOT A PAYABLE AMOUNT. Because it is status-blind it stays positive on documents that can accept no payment at all -- a cancelled / archived / expired order, a voided invoice, a fully-refunded order -- and it OVERSTATES what is owed on an allowance-settled order (a standalone concession refund reversed goods or tax: balance_due correctly settles to 0 while the remainder does not). Collecting amount_due on either shape creates an overpayment, and the payment endpoints will refuse it with order_not_payable (422). To decide how much to collect, take the amount from the payment surface you are about to call (POST /v1/orders/{id}/payments validates and caps server-side); to reconcile against AR aging or the GL AR control account, use balance_due.
ship, pick_up, local_delivery order, manual, proforma, correction 
