Carts & orders
Changing carts or validating them requires a WRITE credential; see Authentication & scopes. GET on carts and orders works with READ.
Carts and order_id
Section titled “Carts and order_id”A cart is still an order in Fleet’s model: the path uses order_id even while the basket is open. Once the flow advances, the same identifier continues to identify that order in the orders endpoints. That is why create-cart responses hand back an order_id.
Line items and catalog
Section titled “Line items and catalog”Each cart line refers to a catalog product, a delivery country, and optional extras such as assignee, shipping address, and sometimes keyboard layout when pricing rules require it. The Catalog guide explains how groups, products, and keyboard choices relate; the API reference shows the exact JSON shape for order_items.
Acquisition mode
Section titled “Acquisition mode”Orders distinguish leasing vs one-time purchase (BUY). The default leans toward leasing unless you override it; semantics and fields are documented per operation in API reference.
Patching a cart
Section titled “Patching a cart”You can change the purchaser, replace line items, or adjust acquisition mode—at least one of those dimensions must be present in a patch. Use API reference for validation rules (minimum items, required fields on each line).
Validate
Section titled “Validate”Validate is the step that moves the workflow forward from an open cart: you supply who is purchasing and optionally who signs. Fleet may enforce business rules (devices present, payment readiness, signatory eligibility, etc.). Error codes such as VALIDATE_CART_NO_DEVICES or PAYMENT_METHOD_REQUIRED are listed on the validate operation in API reference.
Orders after checkout
Section titled “Orders after checkout”List orders gives a paginated summary suitable for history views; get order returns a richer read model (status, devices, financial highlights—exact fields in API reference).