Errors

Error envelope, full code matrix, and per-code troubleshooting.

Error response shape

All non-2xx responses share this envelope:

{
  "error": {
    "code": "past_order_cutoff",
    "message": "The order window for this auction closed at 2026-04-20T12:00:00+09:00.",
    "request_id": "req_8829374",
    "details": {
      "cutoff_at": "2026-04-20T12:00:00+09:00",
      "now": "2026-04-20T12:30:00+09:00"
    }
  }
}

Branch on error.code only. error.message is human-readable English and may evolve. details is structured supplementary info — fields vary per code.

request_id is also returned as the X-Request-Id response header. Include it in any support request.

HTTP → code matrix

HTTP	error.code values
400	validation_error, missing_idempotency_key, missing_max_bid, invalid_cursor, mixed_source_pagination_unsupported
401	missing_api_key, invalid_api_key
403	ip_not_allowed, invalid_status_transition (partner attempting LMN-owned transition)
404	vehicle_not_found, order_not_found, order_vehicle_snapshot_not_found
409	invalid_status_transition, past_order_cutoff, past_secondary_inspection_cutoff, duplicate_order
410	vehicle_unavailable
422	idempotency_key_reused
429	rate_limited
500	internal_error
503	dealer_upstream_unavailable

Per-code troubleshooting

Code	HTTP	Meaning	When	What to do
validation_error	400	Request shape failed validation.	Bad enum, missing field, model without make, ids > 100, from without to.	Inspect error.details.issues[].path. Fix the request; do not retry as-is.
missing_idempotency_key	400	Idempotency-Key header absent on order creation.	POST /v1/orders without header.	Add UUID v4 header, retry.
invalid_cursor	400	Cursor invalid, expired, or sort-mismatched.	Resending a cursor after changing sort=.	Restart pagination from page 1 with the desired sort.
missing_max_bid	400	Auction vehicle requires max_bid_amount_usd.	POST with null/omitted/below-listing bid.	Add max_bid_amount_usd (integer > 0, ≥ listing). Not required for buy-now.
missing_api_key	401	x-api-key header absent.	Any request without header.	Add the header.
invalid_api_key	401	Key not recognized, revoked, or wrong env.	Sandbox key against production URL, or revoked key.	Verify env (sandbox vs production); rotate if compromised.
ip_not_allowed	403	Source IP not in allowlist.	Egress IP missing from the key’s allowlist. Production keys only — sandbox trial keys have no allowlist and never return this.	Add the IP yourself: partner console → Keys → the key → Allowlist. Check egress NAT stability; if your backend has rotating IPs, certify on sandbox first.
invalid_status_transition	403 / 409	Requested transition not permitted.	403 = partner attempted an LMN-owned status (secondary_inspection_in_progress, secondary_inspection_ready, acquiring, secured, export_processing, in_transit); details.reason: "partner_not_authorized". 409 = sequence violation (e.g., delivered from non-customs, DELETE from non-placed); details.reason: "out_of_sequence". details.current_status set in both cases.	Re-fetch GET /v1/orders/{id} to see current state. Only use partner-permitted transitions: in_transit → customs, customs → delivered.
vehicle_not_found	404	Unknown or unavailable vehicle ID.	Stale ID, wrong-env ID, a dealer (encar_*) detail page whose upstream advertisement is no longer active / marked SOLD or WAIT, or a dealer listing currently under contract (계약중) on Encar.	Refresh the listing; confirm correct base URL. For a SOLD / WAIT dealer car, treat this as no longer available to buy and remove or disable the listing in your UI. For an under-contract dealer car, this is reversible — don’t remove the listing permanently; it can resolve normally again once the contract falls through. Cars you have already ordered are exempt — their detail still resolves from your stored order snapshot, so a purchased vehicle won’t return this error.
order_not_found	404	Unknown order ID for this key.	Wrong env, cross-key ID, or deleted.	Confirm correct base URL; the ID belongs to your account.
order_vehicle_snapshot_not_found	404	Order exists, but no purchased-vehicle snapshot is stored.	GET /v1/orders/{id}/vehicle for a historical order created before snapshot storage.	Use live GET /v1/vehicles/{vehicle_id} only if the listing still exists; otherwise contact LMN for manual recovery.
past_order_cutoff	409	POST after the auction’s cutoff.	auction_date − N min (your integration’s lead time; default 1440 = 24h) already passed.	Inform dealer that the order window is closed.
past_secondary_inspection_cutoff	409	POST with secondary_inspection_required: true after the inspection request window.	End of day (auction day − 2, your integration’s local time) already passed — read secondary_inspection_cutoff_at on the Vehicle resource.	Offer the dealer the same order without inspection (secondary_inspection_required: false) while order_cutoff_at is still open.
duplicate_order	409	Active order already exists for this vehicle.	Repeat POST while a prior order is not terminal. details.existing_order_id references it.	Redirect user to existing order page. Do not auto-retry.
idempotency_key_reused	422	Same Idempotency-Key with a different vehicle_id, or the same vehicle with a different secondary_inspection_required.	Client-library bug reusing keys across logical requests, or a retry that flipped the inspection flag.	Inspect details.original_vehicle_id / details.original_secondary_inspection_required. Generate a fresh key per new order.
vehicle_unavailable	410	Vehicle no longer available.	Dealer or buy-now listing disappeared before LMN could complete the purchase.	Move order to failed in UI once the order snapshot reflects failure_reason: "vehicle_unavailable"; notify dealer.
rate_limited	429	Two distinct conditions share this code — one transient, one permanent. See Telling the two 429s apart.	Transient: more than 5 test-webhook fires per minute on one Eagle Eye watch. Permanent: a sandbox trial key has spent its lifetime call budget.	Branch on error.details. Present (limit + used) → budget exhausted, stop retrying. Absent → test-webhook throttle, retry after ~60s.
internal_error	500	Server-side failure.	Rare; LMN on-call is paged automatically. Body carries only a generic message — no stack traces.	Retry with exponential backoff (3 tries). If persistent, share request_id with support.
mixed_source_pagination_unsupported	400	cursor passed with mixed auction+dealer source.	Trying to paginate beyond page 1 on a query like source=glovis,dealer&cursor=….	Restart pagination per source — issue separate requests with source=glovis and source=dealer. The first page of a mixed query is supported; deeper iteration is not.
dealer_upstream_unavailable	503	A dealer upstream (Encar or Danawa) is unreachable or returned an unexpected response shape.	Transient dealer-source outage, network blip, bot-protection interstitial, or extractor drift. Mixed requests degrade gracefully instead of this error, with two headers: X-LMN-Partial-Dealer-Unavailable: 1 (binary flag, always the literal 1) and X-LMN-Dealer-Unavailable-Sources: <csv> — a comma-separated list of the dealer source names that failed (e.g. encar, danawa, or encar,danawa); a pure dealer request fails with 503 only when all dealer sources are down (one source down still returns the survivor’s rows + the header).	Retry after a short backoff (5–30s). If persistent (> 5 min for a single ID, > 2 min for list), include request_id and the failing dealer query in a support note — auction requests are unaffected during dealer outages.

Telling the two 429s apart

429 rate_limited covers two conditions with opposite remedies. Neither sends a Retry-After header, so you must discriminate on the body:

	Test webhook throttle	Trial budget exhausted
Where	POST /v1/eagle-eye/watches/{watch_id}/test-webhook only	Any authenticated /v1 endpoint
error.details	absent	{ "limit": 1000, "used": 1000 }
X-Quota-* headers	not set by this condition	present
Clears on its own?	Yes — within 60 seconds	No — never
Correct response	Wait ~60s and retry	Stop retrying; get more budget

if (res.status === 429) {
  const { error } = await res.json();
  if (error.details?.limit != null) {
    // Lifetime budget spent. Retrying will never succeed.
    throw new QuotaExhausted(error.details);
  }
  // Transient test-webhook throttle — safe to retry.
  await sleep(60_000);
}

Do not write a blanket “429 → exponential backoff” handler. It is correct for one of these and an infinite loop for the other.

Test webhook throttle

POST /v1/eagle-eye/watches/{watch_id}/test-webhook is limited to 5 fires per minute per watch, counted over a rolling 60-second window. Exceeding it returns:

{
  "error": {
    "code": "rate_limited",
    "message": "Test webhook limit reached (5/min per list) — try again in a minute",
    "request_id": "req_8829374"
  }
}

No details object, and no Retry-After. The window is rolling, so capacity returns gradually as older fires age out — waiting a full minute after the last accepted fire is always sufficient. This is the only throttle enforced on /v1; the fair-use targets in Authentication are not enforced server-side.

Trial budget exhausted

Sandbox keys minted from a trial (self-serve) account carry a lifetime call budget — 1,000 calls by default. When it runs out, every subsequent request returns 429:

{
  "error": {
    "code": "rate_limited",
    "message": "This trial key's 1000-call budget is exhausted. Request production access at console.lmnauto.com or contact [e-mail].",
    "request_id": "req_8829374",
    "details": { "limit": 1000, "used": 1000 }
  }
}

This is not a throttle, and backing off will not clear it. The budget is a lifetime total, not a per-minute or per-month window — it does not refill on its own. A client that treats 429 as “retry with exponential backoff” will retry forever. error.details.limit being present is what distinguishes this from the test-webhook throttle, which does clear.

The API sends no Retry-After header on this response, because there is no time after which the request would succeed.

How to resolve it

Situation	Action
Still building, need more calls	Request production access in the console and say what you’re building. We can raise your sandbox budget without waiting for full approval.
Integration is ready	Request production access. Approval unlocks production key minting, and production keys carry no call budget.
Just need a few more calls now	Mint a new key (not rotate — see below). Trial accounts may hold 2 active sandbox keys, each with its own budget.

Rotating an exhausted key does not reset its budget. Rotation deliberately carries over both the budget and the calls already used, so the new key is exhausted the moment it’s created — otherwise rotation would be an unlimited free-budget loop. To get a fresh budget you must create a new key, which is a different button.

Staying ahead of it

Budgeted keys carry the remaining count on every response, including successful ones:

X-Quota-Limit: 1000
X-Quota-Remaining: 6

X-Quota-Remaining is computed after the current request is counted. Log it, or alert when it drops below a threshold, rather than waiting for the first 429.

Keys with no budget — every production key, plus any sandbox key whose budget has been lifted — send no quota headers at all. Absence means unlimited, not zero; a client that parses a missing header as 0 will lock itself out of a perfectly healthy production key.