Webhooks overview

Real-time event notifications for order state changes, Eagle Eye watch activity, and chat messages.

LMN sends webhooks to your registered URL on server-side state changes and observed external events. Most partner-initiated API calls are confirmed by the API response and do not also fire a webhook — the exception is the partner’s decision at secondary_inspection_ready (confirm / decline via DELETE), which fires order.status_changed in addition to the synchronous response (amended 2026-07-06; see the firing-rules table below).

Event families

Family	Event type	When it fires
Orders	order.status_changed	LMN-owned order lifecycle transitions.
Orders	order.auction_rescheduled	An auction source changes the scheduled auction date for an active order.
Orders	order.price_updated	A watched listing price changes while an order is still placed.
Orders	order.re_auctioned	A vehicle tied to a terminal order appears again in a new auction round.
Eagle Eye	eagle_eye.match	A saved watch has additions, price changes, or removals.
Chat	chat.message.created	LMN produces a dealer-visible chat message (AI agent or human staff reply).
Chat	chat.eagle_eye.match_posted	An Eagle Eye match digest is posted into a chat-created watch’s dealer room (chat-created watches only — see event types).

See event types for payload examples and per-event semantics.

Chat events are opt-in. Unlike Orders and Eagle Eye, chat events are off by default — chat.message.created fires once per visible reply; chat.eagle_eye.match_posted fires once per Eagle Eye digest posted into a dealer’s room. Contact LMN to enable either for your integration; delivery otherwise uses the same webhook URL and secret you already have registered.

Order firing rules

#	Trigger	By	Event type
1	→ placed	Partner POST	—
2	placed → cancelled	Partner DELETE	—
3	placed → secondary_inspection_in_progress (optional)**	LMN	✅ order.status_changed
4	placed → acquiring (skip inspection)	LMN	✅ order.status_changed
5	secondary_inspection_in_progress → secondary_inspection_ready	LMN	✅ order.status_changed
6	secondary_inspection_ready → acquiring (admin decision)	LMN	✅ order.status_changed
7	secondary_inspection_ready → acquiring (partner confirms)***	Partner POST /confirm	✅ order.status_changed
8	secondary_inspection_ready → cancelled (secondary_inspection_failed, admin decision)	LMN	✅ order.status_changed
9	secondary_inspection_ready → cancelled (secondary_inspection_declined, partner declines)***	Partner DELETE	✅ order.status_changed
10	acquiring → secured	LMN	✅ order.status_changed
11	acquiring → failed	LMN	✅ order.status_changed
12	secured → export_processing	LMN	✅ order.status_changed
13	export_processing → in_transit	LMN	✅ order.status_changed
14	in_transit → customs	Partner POST	—
15	customs → delivered	Partner POST	—
16	placed → cancelled (LMN auto)*	LMN auto	✅ order.status_changed
17	auction_date shifts †	Source reschedule	✅ order.auction_rescheduled
18	listing_price shifts on placed †	Upstream price refresh	✅ order.price_updated
19	Terminal vehicle re-listed †	Scraper match by license plate	✅ order.re_auctioned

* cancellation_reason is one of auction_rescheduled_too_soon, auction_cancelled (pre-acquiring), seller_withdrew (pre-acquiring). ** Inspection is optional — placed → acquiring directly (row 4) remains valid for orders that skip inspection. secondary_inspection_in_progress and secondary_inspection_ready are LMN-owned statuses; partners cannot set them directly via the status-push endpoint. *** At secondary_inspection_ready, the outcome can be either driver: LMN/admin decides (rows 6, 8) or the partner decides via POST /v1/orders/{id}/confirm or DELETE /v1/orders/{id} (rows 7, 9). Both drivers fire order.status_changed (amended 2026-07-06 — previously the partner-driven rows fired nothing; the partner’s event pipe now carries every outcome of the decision point), in addition to the synchronous API response. Whichever happens first wins; a losing concurrent request gets 409. † No status change — informational signal only.

Eagle Eye firing rule

eagle_eye.match fires per saved watch when LMN observes at least one change worth notifying:

Change	Meaning
additions	New vehicles match the watch’s saved buying condition.
price_changes	Existing matches dropped enough to notify. Price increases do not emit this entry while the vehicle still qualifies.
removals	Previously matched vehicles disappeared, completed auction, or no longer qualify.

Muted watches still collect matches but suppress webhook delivery. Paused watches do not collect new matches until resumed.

Delivery model — fire-and-forget

On state transition, LMN enqueues the event and returns the API/admin response immediately. A background worker picks up pending events on the cron cadence, typically within the next minute. The write path never blocks on webhook delivery.

If your endpoint is slow or down, the order transition still completes immediately. Delivery is retried per the retry policy.

Pilot mode — webhooks optional

For pilot integrations, you may skip registering a webhook URL and rely on polling API reads instead. LMN still records events server-side for every qualifying transition; if no URL is registered, delivery is a no-op (recorded as delivery_skipped in the event log).

Post-pilot (production volume), webhooks become required — LMN cannot support polling at scale.

Self-service event history

LMN exposes the event log for recovery and audit:

Subject	Endpoint
Order	GET /v1/orders/{id}/events
Eagle Eye watch	GET /v1/eagle-eye/watches/{watch_id}/events

Each entry includes delivery status, attempts, response code, and the payload LMN sent. Useful for “did I miss a webhook?” debugging without contacting LMN support.

The two endpoints report delivery_status in different vocabularies. This is long-standing behavior, not a bug, but it will break a shared parser:

Endpoint	delivery_status values
GET /v1/orders/{id}/events	pending · delivering · delivered · delivery_failed · delivery_skipped
GET /v1/eagle-eye/watches/{watch_id}/events	pending · delivered · failed

The watch endpoint collapses the internal states: delivering folds into pending, and both delivery_failed and delivery_skipped fold into failed.

The consequence worth knowing: on a watch event, failed does not tell you whether your endpoint rejected the delivery or whether no URL was registered at the time — two situations with opposite remedies. Only the order endpoint distinguishes them. If you need that distinction for a watch event, check whether a webhook URL is registered for that environment before assuming your receiver is at fault.

The partner console shows the same log per order, and adds two self-service actions: View payload (inspect the exact JSON, read-only) and Replay (re-send a past event to your endpoint). See Replaying a webhook — note that a replay reuses the original event_id, which matters if your handler deduplicates.