Event types

Order, Eagle Eye, and Chat webhook event types.

Order events carry a full Order snapshot in data.order so your handler can act without a follow-up GET. Eagle Eye events carry the watch context plus the vehicles or vehicle IDs that changed. Chat events carry a preview of a dealer-visible chat message so you can alert the dealer without polling the widget stream.

Order payload parity (v1.18+): the data.order field in every order webhook is structurally identical to the response of GET /v1/orders/{id} — same field names, types, nullability, and enrichment (including is_highest_bid and current_max_bid_usd). You can reuse the same Order type and deserializer across order reads and order webhooks.

Eagle Eye vehicle parity: vehicle objects inside eagle_eye.match additions and price_changes use the same VehicleSummary schema returned by GET /v1/vehicles. Eagle Eye adds watch and signal metadata around that vehicle object; it does not define a separate vehicle model.

Examples below are abbreviated for brevity. Order webhook payloads include every field documented under Get an order, not only the ones shown here. Eagle Eye vehicle examples are also abbreviated; build against the shared VehicleSummary schema.

order.status_changed

Fires on every server-side status transition. Includes the previous status for reconstruction.

{
  "id": "evt_01HXYZ...",
  "type": "order.status_changed",
  "occurred_at": "2026-04-20T13:30:00+09:00",
  "data": {
    "previous_status": "acquiring",
    "order": {
      "id": "01HXYZ...",
      "vehicle_id": "glovis_20260420_1064_2345",
      "status": "secured",
      "max_bid_amount_usd": 15500,
      "amounts": {
        "purchase_price_usd": 14800,
        "auction_fee_usd": 234
      },
      "failure_reason": null,
      "shipment": null,
      "created_at": "2026-04-11T10:00:00+09:00",
      "updated_at": "2026-04-20T13:30:00+09:00"
    }
  }
}

Status transitions that fire this event

Transition	Driver
placed → secondary_inspection_in_progress	LMN starts the optional pre-acquisition inspection
placed → acquiring	LMN starts bidding/purchasing (inspection skipped)
secondary_inspection_in_progress → secondary_inspection_ready	Inspection completed; ready for an acquisition decision
secondary_inspection_ready → acquiring (admin decision or partner confirms)	Admin reviews the inspection and starts bidding/purchasing, or the partner calls POST /v1/orders/{id}/confirm
secondary_inspection_ready → cancelled (admin decision or partner declines)	Admin judges the inspection failed (cancellation_reason: secondary_inspection_failed), or the partner calls DELETE /v1/orders/{id} (cancellation_reason: secondary_inspection_declined)
acquiring → secured	LMN won/purchased
acquiring → failed	LMN lost auction or purchase failed
secured → export_processing	Title transferred to LMN; Korean export begins
export_processing → in_transit	Bill of Lading issued; vessel departed Korean port
placed → cancelled (LMN auto)	Reschedule-too-soon / source-cancel / seller-withdraw

secondary_inspection_ready is a decision point with two possible drivers: admin or the partner directly (confirm/decline). Both drivers fire this webhook — the partner’s event pipe carries every outcome of the decision point (amended 2026-07-06; see below).

Partner-initiated transitions (placed creation, placed → cancelled via DELETE, in_transit → customs, customs → delivered) are confirmed by the API response and do not fire webhooks. The exception is the secondary_inspection_ready decision point: secondary_inspection_ready → acquiring via POST /v1/orders/{id}/confirm and secondary_inspection_ready → cancelled via DELETE /v1/orders/{id} (cancellation_reason: secondary_inspection_declined) do fire order.status_changed (previous_status: secondary_inspection_ready), in addition to the synchronous API response.

Inspection-ready example (v1.49)

When the inspection completes, the ready-transition event carries the LMN URL of the inspection report (data.order.secondary_inspection_url, nullable) so you can surface it to your dealer at the confirm/decline decision point:

{
  "id": "evt_01HJKL...",
  "type": "order.status_changed",
  "occurred_at": "2026-07-15T11:00:00+09:00",
  "data": {
    "previous_status": "secondary_inspection_in_progress",
    "order": {
      "id": "01HDEF...",
      "status": "secondary_inspection_ready",
      "secondary_inspection_required": true,
      "secondary_inspection_url": "https://lmnauto.com/en/auction/inspection-report/8b1e2f3a-0000-4000-8000-000000000000",
      "amounts": {
        "purchase_price_usd": null,
        "auction_fee_usd": null
      }
    }
  }
}

The URL stays on the order afterwards (GET /v1/orders/{id} and later webhooks include it too). It is null when no report link was recorded at the transition.

Failed-auction example

{
  "id": "evt_01HABC...",
  "type": "order.status_changed",
  "occurred_at": "2026-04-20T13:45:00+09:00",
  "data": {
    "previous_status": "acquiring",
    "order": {
      "id": "01HDEF...",
      "status": "failed",
      "failure_reason": "outbid",
      "amounts": {
        "purchase_price_usd": null,
        "auction_fee_usd": null
      }
    }
  }
}

failure_reason enum (terminal failed, reachable from acquiring only):

• outbid — lost to external bidder at auction.
• outbid_internally — another partner’s higher bid won. All competing placed orders on the same auction lot enter acquiring together before resolution, so each competitor sees a clean placed → acquiring → failed sequence.
• vehicle_unavailable — LMN’s dealer purchase attempt failed (car sold to another buyer).
• auction_cancelled — auction event cancelled after LMN began bidding.
• auction_passed — vehicle passed at auction, OR zombie cleanup at auction_date + 24h (see below).
• seller_withdrew — seller withdrew the car after LMN started attempting to acquire.

Zombie-cleanup variant

If LMN never picked up a placed order and the auction has been over for 24 hours, the system auto-resolves it with failure_reason: auction_passed. The webhook collapses the synthetic intermediate state — previous_status is placed (not acquiring):

{
  "id": "evt_01HZOM...",
  "type": "order.status_changed",
  "occurred_at": "2026-04-21T13:00:00+09:00",
  "data": {
    "previous_status": "placed",
    "order": {
      "id": "01HXYZ...",
      "status": "failed",
      "failure_reason": "auction_passed",
      "acquired_at": null
    }
  }
}

Treat this as a regular failed event. You can recognize the zombie-cleanup variant by the combination previous_status: "placed" + failure_reason: "auction_passed" + acquired_at: null — a normally-failed auction order transitions from acquiring, not placed.

Cancellation example

{
  "id": "evt_01HCAN...",
  "type": "order.status_changed",
  "occurred_at": "2026-04-19T08:00:00+09:00",
  "data": {
    "previous_status": "placed",
    "order": {
      "status": "cancelled",
      "cancellation_reason": "auction_cancelled"
    }
  }
}

cancellation_reason enum (terminal cancelled, reachable from placed or secondary_inspection_ready):

• dealer_cancelled — partner sent DELETE while placed.
• auction_rescheduled_too_soon — LMN auto, auction rescheduled past order cutoff.
• auction_cancelled — LMN auto, auction event cancelled before LMN started bidding.
• seller_withdrew — LMN auto, seller pulled dealer listing before LMN started purchase.
• secondary_inspection_failed — LMN/admin cancelled at secondary_inspection_ready (inspection found disqualifying issues); this one fires order.status_changed.
• secondary_inspection_declined — partner sent DELETE while secondary_inspection_ready. Partner-initiated, but this decision does fire order.status_changed (previous_status: secondary_inspection_ready, amended 2026-07-06) in addition to being echoed on GET /v1/orders/{id} and in the DELETE response.

failure_reason and cancellation_reason are mutually exclusive — an order has one or the other, never both. For reasons that can appear in either enum (auction_cancelled, seller_withdrew), the order’s current status at the moment of the upstream event decides the terminal.

order.auction_rescheduled

Fires when the auction source postpones or advances an auction, shifting auction_date and recomputing order_cutoff_at. No status change.

{
  "id": "evt_01HRES...",
  "type": "order.auction_rescheduled",
  "occurred_at": "2026-04-14T08:15:00+09:00",
  "data": {
    "previous_auction_date": "2026-04-20T13:00:00+09:00",
    "order": {
      "auction_date": "2026-04-22T13:00:00+09:00",
      "order_cutoff_at": "2026-04-21T00:00:00+09:00"
    }
  }
}

Compare data.previous_auction_date against data.order.auction_date to detect direction and magnitude. Update dealer-facing deadlines accordingly.

If a reschedule moves auction_date so close that order_cutoff_at is already in the past on a placed order, LMN auto-cancels with cancellation_reason: "auction_rescheduled_too_soon" and fires a separate order.status_changed event. Orders already in acquiring or later are unaffected (LMN is committed; the auction proceeds on the new date).

order.price_updated

Fires when the vehicle backing an active placed order has its listing_price updated by the upstream scraper. No status change. The payload keys (previous_listing_usd / current_listing_usd) keep the _usd suffix for webhook-event convention; they refer to the same underlying value as pricing.listing_price on the vehicle. Useful for partners whose bid strategy depends on the current market estimate — a price drop may mean the dealer should raise max_bid_amount_usd to stay competitive, while a spike may mean the current max_bid is now insufficient.

{
  "id": "evt_01HJPU...",
  "type": "order.price_updated",
  "occurred_at": "2026-04-22T03:02:10+09:00",
  "data": {
    "previous_listing_usd": 14200,
    "current_listing_usd": 13650,
    "delta_usd": -550,
    "delta_pct": -3.9,
    "order": {
      "id": "01HXYZ...",
      "vehicle_id": "glovis_20260420_1064_2345",
      "status": "placed",
      "max_bid_amount_usd": 15000
    }
  }
}

Semantics:

• delta_usd is negative when the price dropped (partner-friendly).
• delta_pct is rounded to 1 decimal place and is null if previous_listing_usd was 0.
• Fires at most once per actual change — identical refreshes to the same value are deduped server-side.
• Fires only while the order is in placed — terminal-state and post-acquiring orders ignore market refreshes.

order.re_auctioned

Fires when a vehicle tied to one of your terminal orders (status failed / cancelled / delivered) reappears in a new auction round. Matched by Korean license plate across auction houses, so the same physical car is caught even if it moves from Glovis to SK or Lotte between listings.

{
  "id": "evt_01HK5M...",
  "type": "order.re_auctioned",
  "occurred_at": "2026-04-24T00:15:00+09:00",
  "data": {
    "previous_vehicle_id": "glovis_20260410_1062_5000",
    "new_vehicle_id": "glovis_20260428_1070_3021",
    "new_auction_date": "2026-04-28T09:00:00+09:00",
    "license_plate": "12가 3456",
    "order": {
      "id": "01HWYZ...",
      "status": "failed",
      "failure_reason": "outbid"
    }
  }
}

Use case: the dealer originally bid, lost (or cancelled), and wants a second chance. On receiving this event, surface the new vehicle_id back to the dealer UI and let them re-POST /v1/orders if still interested.

Semantics:

• The attached data.order is the original terminal order — NOT a new order. No new order is implicitly created.
• Fires at most once per (license_plate, new_auction_date) — no duplicates during re-scrapes.
• data.previous_vehicle_id is the ID from the terminal order; data.new_vehicle_id is the current listing’s ID.
• data.new_auction_date is in KST ISO 8601 with +09:00 offset.

eagle_eye.match

Fires when a saved Eagle Eye watch has at least one addition, price change, or removal. The payload is batched per watch and includes enough context for a partner UI to explain why the vehicle appeared.

Test events: a sandbox test fire (POST /v1/eagle-eye/watches/{watch_id}/test-webhook, or the console’s “Send test webhook” action) delivers this same event type with data.is_test: true added. The key is present on every test event and never on organic ones — check it before downstream automation acts on an addition. See Eagle Eye → Testing your receiver.

{
  "id": "evt_01HZX0Q...",
  "type": "eagle_eye.match",
  "occurred_at": "2026-06-09T12:00:00+09:00",
  "data": {
    "watch_id": "wat_01HZW...",
    "watch_name": "GLE 450 watch",
    "batch_id": "batch_01HZX0M9R5Q7TZWN4D5VG3F2KA",
    "evaluated_at": "2026-06-09T03:00:00.000Z",
    "additions": [
      {
        "vehicle": {
          "id": "glovis_20260609_1234_5678",
          "source": "glovis",
          "make": "Mercedes-Benz",
          "model": "GLE-Class",
          "year": 2022,
          "pricing": {
            "listing_price": 31000000,
            "currency": "KRW"
          }
        },
        "match_reason": ["filters", "signals.undervalued"],
        "signal_detail": {
          "undervalued": {
            "reference_price_krw": 38500000,
            "listing_price_krw": 31000000,
            "delta_pct": 19.5
          }
        }
      }
    ],
    "price_changes": [
      {
        "vehicle": {
          "id": "sk_20260609_88_1001",
          "source": "sk",
          "pricing": {
            "listing_price": 30000000,
            "currency": "KRW"
          }
        },
        "previous": {
          "price_krw": 32500000,
          "observed_at": "2026-06-08T03:00:00.000Z"
        },
        "match_reason": ["filters", "signals.price_drop"],
        "signal_detail": {
          "price_drop": {
            "previous_price_krw": 32500000,
            "current_price_krw": 30000000,
            "drop_pct": 7.7,
            "min_drop_pct_configured": 5
          }
        }
      }
    ],
    "removals": [
      {
        "vehicle_id": "glovis_20260601_1234_1000",
        "reason": "auction_complete"
      }
    ]
  }
}

Signal detail

Signal-driven matches include signal_detail so product teams can show the dealer why the alert matters:

Signal	Detail fields
repeat_listing	bucket, listing_count, cumulative_drop_pct, window_days
undervalued	reference_price_krw, listing_price_krw, delta_pct
price_drop	previous_price_krw, current_price_krw, drop_pct, min_drop_pct_configured

price_drop is drop-only. A price increase does not carry signals.price_drop; if the vehicle still qualifies, the current match updates silently and no price_changes webhook entry is emitted. If the increase makes it fail the watch’s filters, LMN sends a removal.

Static lists

The rule above — drop-only, no emission on NULL→value, no emission on rises — applies only to automatic watches (automatic_list_update: true).

On a static list (automatic_list_update: false), membership only changes through POST …/matches / POST …/matches/remove (no webhook fires for those calls — you performed the action yourself). Once a car is a member, every price transition LMN observes on it emits via this webhook: a price appearing on a previously un-priced listing (NULL→value — the core static-list use case), a drop, and a rise. These entries carry match_reason: ["manual"] instead of filters / signals.*, and never carry signal_detail — signals cannot be configured on static lists. Static lists never produce additions entries — LMN only monitors cars you’ve explicitly added; it never adds new ones on its own.

A non-hidden static-list member that disappears from live inventory (sold/delisted) still produces a removals entry with reason: "auction_complete", same as an automatic watch.

See Eagle Eye endpoints — Static lists for how cars enter and leave a static list.

Removal reasons

Reason	Meaning
delisted	Dealer inventory listing disappeared.
auction_complete	Auction listing finished.
price_above_threshold	Vehicle rose above the watch’s configured price cap.
under_contract	The dealer listing is under contract (계약중) on Encar — a buyer has placed a deposit and the car is not currently purchasable. Only produced for a dealer car tracked on a static list (automatic_list_update: false).

under_contract is the only reversible reason, and it’s static-list-only. Contracts fall through. When that happens, a static-list member reappears in the match list as a new entry in additions on this same eagle_eye.match event — there is no separate event type for a revival. On an automatic (filter-based) watch, the same real-world event still removes the dealer car from the match list, but is reported as reason: "delisted" — automatic watches don’t distinguish a contract from a genuine sale; the car can still come back as a plain new additions entry once it’s purchasable again, just without the distinct reason label on the way out. Either way, don’t treat a dealer-car removal as necessarily final.

This list is not exhaustive. Handle an unrecognized reason defensively (per conventions) rather than with a switch that has no default case — LMN may add reasons over time.

Hiding a match via POST /v1/eagle-eye/watches/{watch_id}/matches/hide is a view-state change on your side only — it never produces a removals entry on this webhook.

Use GET /v1/eagle-eye/watches/{watch_id}/events to recover the exact webhook payload history for a watch.

chat.message.created

Fires when LMN produces a dealer-visible message in your embedded chat — an AI agent reply or a human staff reply. One event per message. A question that triggers an inventory search may produce two events in quick succession: a brief interim acknowledgement (e.g. “Let me check inventory…”) followed shortly by the full reply. Receivers should expect this and not treat it as a duplicate.

Off by default. This event is high-volume, so it isn’t sent unless your integration has subscribed. Contact LMN to enable it.

{
  "id": "evt_01J...",
  "type": "chat.message.created",
  "occurred_at": "2026-07-03T14:02:11+09:00",
  "data": {
    "session_id": "01J...",
    "message_id": "01J...",
    "external_user_id": "your-dealer-42",
    "display_name": "Adamu Motors",
    "kind": "assistant",
    "origin": "widget",
    "direction": "outbound",
    "text_preview": "I found 3 Sorentos under your budget...",
    "has_ui_blocks": true,
    "message_created_at": "2026-07-03T14:02:11+09:00"
  }
}

Field notes:

• external_user_id is the id your widget JWT supplied for this dealer — use it to route the alert to the right user. It can be null (the dealer-identity lookup is defensive and the event still fires if it misses) — null-check before routing and fall back to session_id.
• display_name can also be null for the same reason as external_user_id above.
• session_id is the chat thread (one per dealer) — the openable unit for a “you have a new message” link. Use this as your routing fallback when external_user_id is null.
• message_id is ULID-ordered — use it for ordering and unread cursors, not occurred_at.
• text_preview is capped at 240 characters and never includes tool payloads or UI block data. The full conversation is available to the dealer in the widget; has_ui_blocks tells you a rich card (e.g. a vehicle match list) accompanied the text but isn’t itself serialized here.
• kind is assistant for AI agent replies or staff for a human operator reply (takeover mode). Both are treated the same way for alerting purposes.
• origin can be null for messages that predate the widget-origin field; treat a null origin as unknown surface, not an error.
• direction is always outbound today — reserved for future inbound/system message types.

Delivery: identical signing, retry, and idempotency semantics as every other event — see signing and retries. Deliveries are at-least-once, so dedupe on the envelope id. Ordering across retries is not guaranteed; order by data.message_id, not by delivery arrival.

chat.eagle_eye.match_posted

Fires after LMN posts an Eagle Eye match digest into a dealer’s chat room — the same room-visible message the dealer already sees in the widget. Only fires for chat-created (room-associated) watches: watches built through a chat proposal (create_watch / update_watch), which carry a chat_session_id. API-created watches (created directly via POST /v1/eagle-eye/watches) have no room and remain webhook-only — this event never fires for them; they continue to receive eagle_eye.match directly, same as today.

Off by default. Like chat.message.created, this event isn’t sent unless your integration has subscribed. Contact LMN to enable it.

{
  "id": "evt_01J...",
  "type": "chat.eagle_eye.match_posted",
  "occurred_at": "2026-07-03T15:00:00+09:00",
  "data": {
    "session_id": "01J...",
    "external_user_id": "shekel-dealer-42",
    "display_name": "Adamu Motors",
    "watch_id": "wat_01J...",
    "watch_name": "SUV under ₩20M",
    "chat_message_id": "01J...",
    "match_event_id": "evt_01J...",
    "counts": { "additions": 2, "price_changes": 1, "removals": 0 }
  }
}

Field notes:

• session_id is the dealer’s chat room — the deep-link/routing target, same role it plays in chat.message.created.
• external_user_id can be null — dealer identity is resolved defensively by (chat_session_id, partner_id, environment); a missing or ambiguous match never guesses a dealer, it emits null instead. Route by session_id when null.
• display_name can also be null for the same reason.
• watch_id / watch_name identify the Eagle Eye watch that changed; watch_name is null for unnamed watches.
• chat_message_id is the id of the digest message already posted into the room (visible to the dealer in the widget) — use it to deep-link straight to that message, or to dedupe against your own read of the room.
• match_event_id correlates this ping to the eagle_eye.match webhook delivery that triggered it. No vehicle payload is duplicated here — the full additions / price_changes / removals entries live on that event; join on this id to fetch them.
• counts is a summary only — additions, price_changes, removals mirror the lengths of the corresponding arrays on the paired eagle_eye.match event.

Delivery: identical signing, retry, and idempotency semantics as every other event — see signing and retries. Deliveries are at-least-once; dedupe on the envelope id.