Skip to main content
Replay re-sends a webhook LMN already sent you, from the order’s event table in the partner console. You get the real original payload delivered to your registered endpoint — not synthetic test data — which makes it the way to debug “my handler crashed on that event” or “we deployed a fix, does it work now?” against the exact bytes that broke you. Open an order in the console, find the event in the Webhook events table, and press Replay.
A replay arrives with the same X-LMN-Event-Id as the original.This is deliberate — it matches Stripe’s “Resend” behavior, and it means the id you receive still resolves to the original event in your own records.But it collides head-on with the deduplication we tell you to implement in Signing & retries. If your handler rejects already-seen event ids, a replay will be discarded before your business logic runs — you will see nothing arrive and reasonably conclude Replay is broken. It isn’t; your receiver is behaving correctly.Before replaying, either:
  • delete that event_id from your dedupe store (Redis SREM, or whatever you use), or
  • bypass the dedupe check in your test environment, or
  • log before the dedupe check so you can at least confirm the request arrived.

​
What arrives on the wire

Because the timestamp is fresh and the signature is regenerated per attempt, the 5-minute replay window in your verification code applies normally. Verify against the timestamp you receive, exactly as you do for a first delivery or a retry — no special-casing.

​
History lookup contract cutover

Stored history_lookup.completed and history_lookup.failed event bodies are not rewritten when the History API moves to its version-2 envelope. A replay can therefore omit data.history_lookup_schema_version, aggregate, or sources, even when a current GET of the same lookup has those fields. Absence of the version field means the earlier contract. Preserve the original body, parse both generations, and do not replace a historical event with a current GET response. History event replay does not trigger a provider lookup or another credit debit. Its five-minute signature-verification window is separate from the lookup’s five-minute result-content cutoff. See History integration for complete legacy and current examples.
There is no test marker. A replay is indistinguishable from the original delivery by content — unlike the Eagle Eye test webhook, which adds data.is_test: true. That is the point: your handler runs the same code path it runs in production. It also means downstream automation will act on a replay as if it were real. Replay against a test consumer if that matters.

​
Which events can be replayed

Replay is offered per-event, based on the event’s delivery status: A replay cannot itself be replayed — replay the original event again instead.
These are the status names used by the console and by GET /v1/orders/{id}/events. The Eagle Eye watch event log uses a narrower three-value set where delivery_failed and delivery_skipped both read as failed.

​
Single attempt, real status

A replay makes exactly one delivery attempt. There is no retry ladder — the 5-attempt schedule does not apply. The console waits for your endpoint and reports what actually happened: The 10-second timeout is the same one production deliveries use.

​
Environment is strict

A replay is delivered to the endpoint registered for the environment you are viewing:
  • The console’s sandbox view replays to your sandbox endpoint.
  • The console’s production view replays to your production endpoint.
There is no cross-environment path — you cannot replay a production event to a sandbox URL, or the reverse. Switch environments in the console to change the target. If no endpoint is registered for that environment, Replay returns an error and sends nothing — nothing is queued for later, so a replay can never surprise you hours after you register a URL.

​
Rate limit

5 replays per event per minute. Exceeding it returns 429 with a retry hint. The limit is per event, so replaying five different events in the same minute is fine.

​
Replays are invisible to your API reads

A replay is recorded on LMN’s side as its own delivery record, but it is filtered out of every partner-facing read:
  • GET /v1/orders/{id}/events returns only the original business events — never replays.
  • Pagination, cursors, and counts are unaffected.
So testing with Replay never pollutes your event history, and the event_id you received still resolves to exactly one entry there. The original event’s own record is also never modified by a replay: its delivery_status, attempts, response_code, and delivered timestamp stay exactly as they were, even if the replay fails.

​
Viewing a payload without sending it

Every row in the console’s webhook events table has a View payload action that opens the exact JSON LMN sent, read-only. Use it to inspect an event without delivering anything — useful when you only need to see what a field contained, or to diff against what your handler logged. Unlike Replay, View payload is available on every row regardless of delivery status.

​
Errors