Orders & POS

A storefront checkout creates an Order; an in-person POS checkout creates a Sale directly. An Order can also turn into one or more Sales once fulfilled — that link is exposed on the Order detail response below. Staff authentication required for everything on this page.

Orders

GET /api/v1/orders/ filters on source, order_type, status, and a date_from/date_to range.

GET /api/v1/orders/42/ — response data

{
  "id": 42,
  "order_number": "ORD-0042",
  "source": "web",
  "order_type": "delivery",
  "customer": 7,
  "staff": null,
  "branch": 1,
  "status": "processing",
  "payment_preference": "mpesa",
  "notes": "",
  "subtotal": "1450.00",
  "tax": "0.00",
  "shipping_fee": "300.00",
  "discount": "0.00",
  "total": "1750.00",
  "items": [
    {
      "id": 88,
      "product": 201,
      "product_name": "Yellow African Necklace",
      "product_sku": "BEAD-NECKLACE-001",
      "product_slug": "yellow-african-necklace",
      "quantity": 2,
      "subtotal": "1450.00"
    }
  ],
  "fulfillment": { "type": "delivery", "status": "in_transit", "carrier": "third_party" },
  "is_sale": false,
  "sales": [],
  "created_at": "2026-07-20T09:00:00Z",
  "updated_at": "2026-07-20T10:15:00Z"
}

fulfillment.type is "walk_in" when no logistics shipment exists for the order, otherwise "delivery" with the shipment's own status.

Sales (POS)

GET /api/v1/sales/ filters on source, sale_category, payment_status, credit_status, has_refund, and the same date_from/date_to range as Orders. Each sale is made of line items (SaleItem), payments, and optional refunds.

/api/v1/sales/POS/web sales — receipt_number, invoice_number, items, payments, refunds.

/api/v1/pos/sessions/A cashier's till session — opening float through closing count.

/api/v1/pos/transactions/Individual tender events (cash/card/M-Pesa) against a sale, tied to a session.

/api/v1/pos/lookup/Barcode → product lookup for a POS register.

GET only, not a router resource.