Skip to main content

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 reaches secured. 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 be SOLD, 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:
Behavior:
  1. If the vehicle is still live, LMN creates the order normally and captures a fresh at-order-time snapshot.
  2. 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.
  3. 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:
Implication: once you’ve placed the order, you can compute the maximum settlement exposure yourself from 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 with secondary_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 return 201. 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.
At auction time, LMN bids with the highest active 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 immutable VehicleDetail 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.
The response shape is the same as 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 at secondary_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.
Response: 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.
Response: 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 the max_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
Any other state → 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 for POST /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.

delivery_status values

These five values are specific to this endpoint. The Eagle Eye watch event log — GET /v1/eagle-eye/watches/{watch_id}/events — reports a collapsed three-value vocabulary instead: pending, delivered, failed. There, delivering reads as pending, and both delivery_failed and delivery_skipped read as failed.Do not reuse a delivery_status parser across the two endpoints, and do not assume a failed on a watch event means your endpoint rejected the delivery — it may mean no URL was registered. Only this endpoint distinguishes the two. See Self-service event history.

Errors