Webhooks overview

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

LMN sends webhooks to your registered URL for order changes and observed inventory events. order.detail_updated carries the latest partner-visible order snapshot after material changes, whether initiated by LMN, a partner API call, a background job, or a data repair. Existing lifecycle, invoice, Eagle Eye, and chat events remain separate.

Event families

Family	Event type	When it fires
Orders	order.detail_updated	Material changes to an existing order or its bid context; rapid edits may combine into the latest snapshot.
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.
Orders	order.invoice_issued	LMN issued — or re-issued — the commercial invoice for an order. Always on.
Orders	order.invoice_updated	Other public invoice changes, including manual drafts, edits, payment and void.
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

Status transitions use the existing status-event rules below and do not also queue order.detail_updated for that order. Invoice issue/reissue uses order.invoice_issued only. Other invoice changes use order.invoice_updated. Other material order detail edits, including partner-driven changes, queue order.detail_updated. Automatic draft creation during a status transition is covered by its status event. Creating an order alone does not notify that new order; existing orders whose bid context changes can be notified. No-op and timestamp-only writes are silent. Offline orders remain silent.

The detail event uses the existing delivery worker, so it is asynchronous and may combine rapid updates. A related invoice change can update data.order.invoice without changing data.order.updated_at; use the event’s occurred_at as its notification timestamp.

#	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.

Invoice firing rule

order.invoice_issued fires when LMN ops issue an order’s invoice and again on every re-issue (same number, version + 1, data.previous_version set). It does not fire when the draft is created, when the invoice is marked paid, or when it is voided — those changes instead emit order.invoice_updated with the current Order.invoice; the Invoices routes remain available. Always on for any integration with a registered webhook URL; there is no opt-in. The event is written in the same transaction as the invoice version, so an issued version without its event cannot exist; delivery then follows the normal retry policy. See order.invoice_issued for the payload.

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.