Replaying a webhook

Re-send a past webhook to your endpoint from the partner console — real payload, same event id, single attempt.

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

	Behavior on replay
X-LMN-Event-Id	Same as the original. Not a new id.
Request body	Byte-identical to the original delivery, including the event_id embedded in the payload (which matches the header).
X-LMN-Timestamp	Fresh — the send time of the replay, not the original event time.
X-LMN-Signature	Re-signed over the new timestamp and the same body.
URL	Your currently registered endpoint for that environment — not the URL registered when the original was sent.

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.

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:

Delivery status	Replay available	Why
delivered	✅	The main case — re-send something that already succeeded.
delivery_failed	✅	Retries are exhausted; this is how you re-attempt after fixing your endpoint.
delivery_skipped	✅	No endpoint was registered at the time. Register one, then replay.
pending	❌	Not yet delivered — LMN’s delivery worker still owns this event.
delivering	❌	An attempt is in flight right now.

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:

Console shows	Meaning
Replay delivered — your endpoint returned 200.	Your endpoint answered 2xx.
Replay failed — your endpoint returned 500.	Your endpoint answered, with a non-2xx status. That is your status code, verbatim.
Replay failed — your endpoint did not respond within 10s.	Timeout or network error. No HTTP status exists to report.

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

Status	Meaning
404	Event not found under that order, for your account, in that environment.
409	The event is pending/delivering, or is itself a replay, or no webhook endpoint is registered for that environment.
429	Rate limit — 5 replays per event per minute.
503	webhook_config_unavailable — your endpoint is registered; delivery is temporarily unavailable on our side. Retry later.