List products from the Distru catalog (GET /public/v1/products). Filters combine with AND; values within a single list filter combine with OR. Prices and quantities are returned as decimal STRINGS, not numbers, to preserve exact precision - do not parse them as floats. Returns { data, next_page }; next_page is an absolute URL or null.

Fetch one product by id (GET /public/v1/products/{id}). Returns 404 if the id does not exist on this account. Ids are opaque UUID strings - never construct or parse one.

Get on-hand inventory rolled up by a chosen set of attributes (GET /public/v1/inventory). groupings is REQUIRED and must include PRODUCT. Each grouping adds its id field to every row: PRODUCT adds product_id, LOCATION adds location_id, BATCH_NUMBER adds batch_number; omitted groupings are absent from the rows entirely. Groups with zero quantity are omitted, and deactivated products are excluded. Grouping by BATCH_NUMBER drops product-tracked products and always reports reserved as "0". This data is eventually consistent: a write can take about a second to show up here.

List sales orders (GET /public/v1/orders). Status is one of PENDING, PROCESSING, READY_TO_SHIP, DELIVERING, DELIVERED, COMPLETED, CANCELED. Totals are decimal strings. New status values may be added over time, so handle unknown tokens rather than assuming this list is closed.

Fetch one sales order by id (GET /public/v1/orders/{id}), including its line items, charges, and any linked invoices.

List invoices (GET /public/v1/invoices). Status is one of NOT_PAID, PARTIALLY_PAID, FULLY_PAID, OVER_PAID. paid_amount and remaining_amount are decimal strings. A voided invoice keeps its row and carries a voided_datetime.

List company relationships - customers, vendors, and brands all live here (GET /public/v1/companies). A product's brand is a company record, so this is also how you resolve a brand name to a brand_id for product filtering.

Match free-form purchase-order lines against the product catalog and report what could NOT be resolved. Read-only; writes nothing. Returns two buckets: matched (one product, unambiguously) and needs_review (why it stopped, plus every candidate considered). It deliberately does not guess when the catalog is ambiguous - duplicate rows for one product, reissued SKUs, colliding category slugs, and conflicting MSRPs all stop the line and are returned with evidence. Treat needs_review as the point of the tool, not as an error: those lines need a human, and presenting a confident answer for them would be wrong.