POST /v1/orders — Place order
This is a bid commitment, not a payment. No deposit. By POSTing, the partner takes commercial responsibility to pay LMN if (and only if) the order reachessecured. Money flow is described in Conventions.
Response — 201 Created (or 200 OK on idempotent replay)
POST /v1/orders/backfill — Place order from LMN snapshot
Use this when you want to place an order for a dealer vehicle that may already beSOLD, WAIT, or removed upstream, but LMN may have a previously captured snapshot.
Auth, idempotency, request body, response shape, and errors are intentionally the same as POST /v1/orders:
- If the vehicle is still live, LMN creates the order normally and captures a fresh at-order-time snapshot.
- If the vehicle is no longer live (
SOLD,WAIT, deleted, or 404), LMN creates the order from the latest stored vehicle snapshot for your account, if one exists. - If neither live data nor a stored snapshot exists, response remains
404 vehicle_not_found.
Partners do not send snapshot JSON to this endpoint. LMN owns snapshot capture and snapshot reuse.
FX rate is locked at creation
fx_rate (KRW-per-USD) is captured at the moment you POST the order and never changes for the life of that order — not on PATCH, not on status pushes, not when markets move.
That rate drives the purchase_price_usd conversion when the order transitions to secured:
max_bid_amount_usd — no FX surprise on auction day.
If the FX provider was unavailable at creation (rare),
fx_rate is null. In that case LMN applies the settlement-day rate and communicates it offline with the secured transition. This does not happen silently — you’ll see fx_rate: null in the response from the start and can rotate the order if that’s unacceptable.Inspection request cutoff (auction vehicles)
Orders withsecondary_inspection_required: true on an auction vehicle have an earlier deadline than the order itself: LMN needs time to physically inspect the car before auction day.
Rule: inspection requests close at the end of day (auction day − 2) in your integration’s timezone (default Africa/Lagos; the window length and timezone are per-integration config). The rule is calendar-based — the auction’s start time is irrelevant.
Worked example (Lagos): auction on Thursday 2026-07-10 → you can request an inspection any time through Tuesday 2026-07-08, 23:59:59 Lagos time. The precise instant is pre-computed on the Vehicle resource as secondary_inspection_cutoff_at (2026-07-09T08:00:00+09:00 here, serialized in KST offset like order_cutoff_at) — read it from the response, don’t recompute.
Past the cutoff, secondary_inspection_required: true returns 409 past_secondary_inspection_cutoff (with UTC details.secondary_inspection_cutoff_at + details.now). The same order remains placeable with secondary_inspection_required: false until order_cutoff_at. A request arriving exactly at the cutoff instant is accepted.
Dealer (encar_*) listings are unaffected — no auction date, no inspection cutoff (secondary_inspection_cutoff_at: null).
Competitive bidding
Multiple partners may all order the same auction vehicle. All POSTs return201. The response carries:
is_highest_bid(boolean) — whether your bid is currently the highest among all active orders.current_max_bid_usd(integer) — the highest active bid across all partners.
max_bid_amount_usd. Winner gets secured; losers get failed (failure_reason: "outbid_internally").
Errors
GET /v1/orders — List
Paginated, filterable list of your orders. AND semantics across filters.Sort use cases
Errors
GET /v1/orders/{id} — Detail
Returns the full Order resource — current state, amounts, cutoffs, shipment.
For auction vehicles, response includes recomputed
is_highest_bid and current_max_bid_usd reflecting the latest competitive state.
Full Order schema in Schemas.
GET /v1/orders/{id}/vehicle — Purchased vehicle snapshot
Returns the immutableVehicleDetail snapshot captured when the order was created. This is the durable read path for purchased dealer (encar_*) cars after Encar removes the live listing page.
GET /v1/vehicles/{id} detail. For dealer orders created after this rollout, photos and image URLs inside inspection data are LMN-mirrored https://storage.googleapis.com/lmnauto-auction-data/... URLs, not Encar CDN URLs.
POST /v1/orders/{id}/confirm — Confirm inspection-ready order
Your decision atsecondary_inspection_ready: proceed to purchase. Transitions the order to acquiring. No request body — a body, if sent, is ignored.
To inform the decision, the order carries secondary_inspection_url (v1.49) — the LMN URL of the completed inspection report, included in the ready-transition order.status_changed webhook and on GET /v1/orders/{id}. null when no report link was recorded.
200 OK with the updated Order (status: acquiring).
Allowed only when the order is in secondary_inspection_ready status. Confirm is not idempotent — a retry after success returns 409 (the order has already moved to acquiring). To decline instead, use DELETE /v1/orders/{id} below — it cancels from secondary_inspection_ready with cancellation_reason: secondary_inspection_declined.
Also fires a webhook (amended 2026-07-06). Confirm and decline are partner-initiated, but both now enqueue
order.status_changed (previous_status: secondary_inspection_ready) in addition to the synchronous response — the API response remains the authoritative confirmation; the webhook is a courtesy notification for your event pipe. Webhooks continue to fire for LMN-side transitions too (e.g., placed → secondary_inspection_in_progress, → secondary_inspection_ready).Sandbox: drive a sandbox order to
secondary_inspection_ready via POST /v1/orders/{id}/sandbox-status, then call confirm or DELETE to exercise this flow end-to-end. Confirm behaves identically in sandbox and production.DELETE /v1/orders/{id} — Cancel
Two cancel windows:placed (before LMN commits) and secondary_inspection_ready (decline instead of confirming). Once LMN starts bidding/purchasing (acquiring+), or while an inspection is secondary_inspection_in_progress, cancellation moves offline.
200 OK with the updated Order (status: cancelled). cancellation_reason reflects which window you cancelled from:
No money flow has occurred pre-
secured, so cancellation has no settlement implication. Partner-to-dealer arrangements are outside this API.
Race condition: If you
DELETE while LMN (or a racing confirm) concurrently transitions the order (e.g., placed → acquiring, or secondary_inspection_ready → acquiring), you may receive 409 invalid_status_transition. Re-fetch GET /v1/orders/{id} to see current state.PATCH /v1/orders/{id} — Update max bid
Update themax_bid_amount_usd on an existing order. Useful when you want to raise (or lower) your bid after placing the initial order — e.g., to improve win probability as auction day approaches.
Allowed only while:
status = placed- Current time is before
order_cutoff_at
409 with the specific code. The payload must carry only max_bid_amount_usd; no other fields are mutable via PATCH.
Response
200 OK with the updated Order. is_highest_bid and current_max_bid_usd are recomputed across all active orders on the same vehicle (so if a competing partner has a higher max, your updated order may still come back with is_highest_bid: false).
Errors
Concurrency: PATCH takes the same vehicle-level advisory lock as
POST /v1/orders, so is_highest_bid stays consistent under concurrent bid updates. No need to back off and retry.Idempotency: PATCH does not require
Idempotency-Key. Replaying the same PATCH is safe (sets the same value). If you need strict at-most-once semantics, include your own client-side deduplication.Sandbox status simulation
Use the dedicated Status updates guide forPOST /v1/orders/{id}/sandbox-status, including request fields, lifecycle behavior, QA cases, and response examples.
GET /v1/orders/{id}/events — Event history
Returns the LMN-side webhook event log for the order — every event LMN attempted to deliver, with current delivery state. Useful for self-service debugging without contacting LMN support.Response — 200 OK
type is one of the four order-scoped event types (order.*) in webhooks → event types — watch-scoped eagle_eye.match and chat events never appear on an order’s log. payload is the exact JSON body LMN sent (or will send) to your webhook URL — same shape your endpoint receives.