Orders are the central commerce resource in Flint. Every sale flows through an order: it holds line items, discounts, charges, tax, a requested tip, and the full pricing and settlement state for the transaction. Other resources attach to orders rather than replacing them: payments, refunds, invoices, checkout sessions, and subscriptions all read from and write back to an order.
Line items come from your catalog (a variant_id or bundle_id, with price and display resolved automatically) or are ad hoc (you provide the name and unit price). Adding inventory_demands makes an ad hoc line item tracked. An order stays open while you build it, then settles through payment: pay it in full, or close it explicitly when no balance remains. pricing_amounts reflects what the order should collect; settlement_amounts reflects what has been paid, refunded, and is still outstanding.
Set delivery_destination when a shipment or local delivery order does not use Flint's delivery selection flow. You can replace the whole destination while the order is open and unpaid, or set delivery_destination to null before removing its last delivery obligation. A checkout delivery selection controls the field while that selection is active, and payment sets frozen_at. Correct a later delivery problem on fulfillment.recipient; that changes where the fulfillment runs without rewriting what the buyer committed to.
Use PATCH /v1/orders/{order_id} for scalar order changes. The same request can update metadata, delivery_destination, tax, and requested_tip. Set requested_tip to a fixed amount_money or a percent; set it to null to clear the current request. Set delivery_destination to null to clear it. Metadata values merge by key, and a null value removes that key.
Remove one line item or charge with its DELETE route. Remove several discounts in one request with POST /v1/orders/{order_id}/discounts/remove. Use POST /v1/orders/{order_id}/discounts/reprice after an eligibility input changes and you want Flint to recalculate the applied discounts.
If any line item resolves to a variant with inventory_tracking: "tracked", the order needs an inventory_routing_source before it can hold stock: either a fixed Location or an allocation policy. Flint holds the routed quantity when payment begins, commits it when payment succeeds, and consumes it when fulfillment hands the goods off. inventory_reservation_id points at the claim. If payment succeeds but the stock cannot be committed, inventory_exception_status reads paid_inventory_failed and the order waits for POST /v1/orders/{order_id}/inventory-exception/resolve, unless your settings tell Flint to refund automatically instead. See the Inventory guide for the whole path.
For the model behind this design, see the Orders-first guide. To collect payment against an order, use checkout sessions for hosted payment, invoices for receivables, or payments for direct integration.