Orders
Convert buy-now and accepted-offer flows into auditable orders.
Orders
Orders are the commercial record for both buy-now and negotiated transactions. They carry buyer and seller organization IDs, monetary totals, notes, and the state changes that matter for audit and payout release.
Core Routes
| Route | Purpose |
|---|---|
GET /api/v1/orders | List orders for the active organization |
GET /api/v1/orders/:id | Read a single order |
POST /api/v1/orders | Create an order from a listing or accepted offer |
POST /api/v1/orders/:id/cancel | Cancel an order when the state allows it |
POST /api/v1/orders/:id/fulfill | Mark the order fulfilled |
Create Order Rules
- the listing must be
published - buyers cannot checkout their own listing
fixed_pricelistings can create an order directlyoffer_onlylistings require an acceptedofferId- order totals are calculated from the listing or accepted offer amount
Beta Fee Model
ZenBid calculates totals as:
subtotal: listing buy-now price or accepted offer amountplatformFee: 10% of subtotaltotal: subtotal plus platform fee
Example:
{
"listingId": "11111111-1111-4111-8111-111111111111",
"offerId": "22222222-2222-4222-8222-222222222222",
"clientRequestId": "order-client-1",
"notes": "Fulfill against the accepted commercial scope."
}State Model
Orders move through:
draftpending_paymentpaidfulfillment_pendingfulfilled
They can also branch into:
canceledrefundeddisputed
draft remains part of the shared contract for flows that stage an order before
checkout or handoff, but the current beta API usually creates orders directly
in pending_payment. From there they move to paid after checkout settles and
then to fulfilled when the seller marks delivery complete.
fulfillment_pending remains available for teams that want an extra internal
handoff checkpoint.