Response display currency
Partner owners can choose USD (default), KRW or EUR in Partner Console → Settings. Preferences are separate for production and sandbox and apply across the partner’s API keys. For API-key-authenticated vehicle, Eagle Eye, order and invoice JSON responses:- Existing fields ending
_usdor_krwretain their units and values. - Existing
pricingremains USD. Newdisplay_pricinghas the same pricing structure, with monetary values converted to itscurrency; percentages and rates are unchanged. - New suffix-free fields such as
price,max_bid_amountandamounts.purchase_priceuse the adjacentcurrency. Where an existing field would collide (for example nativepurchase_priceMoney), converted values live indisplay_amountsinstead. display_currencyidentifies the selected preference.display_fx.dateidentifies the daily rate snapshot;display_fx.usd_to_currencyis selected-currency units per USD.- KRW display amounts round to whole won; USD/EUR to two decimal places. Missing source amounts or unavailable FX produce
null, never a fabricated rate. Zero remains zero. - Display prices are estimates, not settlement instructions. Native Money objects, existing invoice
currency/amounts, issued PDFs and order-locked exchange rates remain authoritative and unchanged. Invoicedisplay_amountsare optional display estimates. - Stored webhook payloads, event streams and request/filter units are unchanged.
price_krw: 28000000, price: 18000 and currency: "EUR", while vehicle.pricing.listing_price remains 20000 USD and vehicle.display_pricing.listing_price is 18000 EUR. These are illustrative rates, not a live quote.
Vehicle
Two shapes —VehicleSummary (list view) and Vehicle (single fetch detail).
Eagle Eye reuses
VehicleSummary for vehicles returned in search results, match rows, and eagle_eye.match webhook additions / price_changes. Eagle Eye-specific fields such as watch_id, match_reason, and signal_detail wrap this shared vehicle model.VehicleSummary
Returned byGET /v1/vehicles.
Vehicle (Detail)
VehicleSummary plus:
pricing
pricing groups this vehicle’s prices, fee estimates, same-car history, and market assessment. Every monetary number inside this object is a whole USD integer.
order (ordered vehicle)
Present on every VehicleDetail served by the vehicle endpoints (the one exception is the frozen vehicle blob embedded on the Order resource — see Order). Non-null only when you hold an order with a vehicle snapshot on this car and the response was served from that snapshot — an active or delivered order via GET /v1/vehicles/{id}, or any Encar (encar_*) order (including failed / cancelled) via GET /v1/orders/{id}/vehicle. null for every other caller and path, including every auction and Danawa vehicle.
When
purchase_price_usd is set, pricing on the same response is overridden (unless the stored snapshot has no pricing at all — rare, legacy rows — in which case pricing is returned as stored and only order carries the price): pricing.listing_price is that USD figure, pricing.discount_config.vehicle_discount_pct and fixed_discount_amount are 0 (the purchase price is the negotiated final; no partner discount is applied on top), and pricing.breakdown.estimated_landed is re-derived from it. When no USD figure exists, pricing is the untouched order-time snapshot. pricing.history and pricing.market_assessment pass through unchanged either way.
Worked example — a placed dealer order with a recorded purchase price of ₩34,170,000 at the order’s locked fx_rate (fee components are passed through exactly as frozen at order creation; this partner’s dealer fee is folded into the purchase price, hence dealer_fee: 0):
order is non-null (equivalently order.buyable === false — the two never disagree) and show the order status instead. Show pricing.listing_price as the vehicle price; it already reflects your purchase price when one is recorded. After a failed or cancelled order, call GET /v1/vehicles/{id} for live availability — it answers from live inventory (the current listing, or 404 if the car is gone) with order: null.
Order
Returned byPOST /v1/orders, GET /v1/orders, GET /v1/orders/{id}, DELETE /v1/orders/{id}, POST /v1/orders/{id}/status.
Use GET /v1/orders/{id}/vehicle for the purchased vehicle snapshot. That response is the same VehicleDetail schema as GET /v1/vehicles/{id} and is stored at order creation so dealer purchases remain readable after the live Encar listing is removed. That response also carries order — always non-null there, with buyable: false, keyed to the order you asked for (including failed / cancelled orders) when the order is for an Encar (encar_*) vehicle; auction and Danawa order snapshots come back with order: null and their pricing untouched — and applies the same purchase-price override to pricing.listing_price that GET /v1/vehicles/{id} applies for the ordering partner.
One exception to “every VehicleDetail carries order”: the vehicle object embedded on the Order resource itself (GET /v1/orders/{id}, order webhooks) is the frozen snapshot returned verbatim. It is not overlaid — its pricing.listing_price stays the order-time listing, and order is absent on orders created before v1.61 and null afterwards. Read the purchase price from amounts.purchase_price_usd on the order, or fetch GET /v1/orders/{id}/vehicle for the overlaid detail.
shipment object
null until in_transit; populated by LMN at vessel loading. Stable for the rest of the shipping leg.
Order status enum (11 values)
placed → acquiring directly (skip
inspection) or placed → secondary_inspection_in_progress → secondary_inspection_ready → acquiring (inspected). When
inspection fails, the order is cancelled (reason secondary_inspection_failed), never
failed.
Boundary: statuses up to
in_transit are LMN-driven (server-side). From customs onward, the partner pushes via POST /v1/orders/{id}/status.
failure_reason enum
cancellation_reason enum
failure_reason and cancellation_reason are mutually exclusive — an order has one or the other, never both. For reasons that appear in both enums (auction_cancelled, seller_withdrew), the order’s current status at the moment of the upstream event decides which terminal — and therefore which field — applies.
Settlement
Atsecured: partner owes LMN purchase_price_usd + auction_fee_usd + lmn_commission_usd + ocean_freight_usd − discount_usd, where discount = ceil(purchase_price_usd × rate / 100) + fixed_discount_amount; rate follows pricing.discount_config evaluated against purchase_price_usd (the actual hammer price). The amount due is the invoice LMN issues for the order — read it via GET /v1/orders/{id}/invoice or GET /v1/invoices, and download the PDF from GET /v1/invoices/{invoice_id}/document (see Invoices). The invoice carries a single bundled price; the cost components above are not itemised on the API or the PDF. The invoice is authoritative. Wire transfer same US business day expected.
There is no dealer-deposit concept in this API. Partner-to-dealer arrangements are entirely outside LMN’s scope.
Invoice
Returned byGET /v1/invoices, GET /v1/invoices/{invoice_id}, and GET /v1/orders/{id}/invoice; carried in full on the order.invoice_issued webhook. Lifecycle, number format, and usage in Invoices.
One live (non-void) invoice per order. LMN drafts it automatically when the order reaches secured and issues it from the LMN admin. Amounts are numbers in major units with at most 2 decimals (unlike the whole-USD integers on Order.amounts). Timestamps keep the +09:00 offset.
Invoice amounts object
While
status: draft, amounts are recomputed from the order on every read and may change between reads. They are frozen at issue.
Invoice status enum
OrderInvoiceSummary
Embedded asOrder.invoice on every order response and on data.order.invoice of every order.* webhook. null when the order has no invoice.