Skip to main content

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 _usd or _krw retain their units and values.
  • Existing pricing remains USD. New display_pricing has the same pricing structure, with monetary values converted to its currency; percentages and rates are unchanged.
  • New suffix-free fields such as price, max_bid_amount and amounts.purchase_price use the adjacent currency. Where an existing field would collide (for example native purchase_price Money), converted values live in display_amounts instead.
  • display_currency identifies the selected preference. display_fx.date identifies the daily rate snapshot; display_fx.usd_to_currency is 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. Invoice display_amounts are optional display estimates.
  • Stored webhook payloads, event streams and request/filter units are unchanged.
Example: with EUR selected, a match can contain 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 by GET /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):
How to render: hide Buy whenever 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 by POST /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)

Inspection is optional: an order may go 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

At secured: 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 by GET /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 as Order.invoice on every order response and on data.order.invoice of every order.* webhook. null when the order has no invoice.