> ## Documentation Index
> Fetch the complete documentation index at: https://lmn.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 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](https://console.lmnauto.com). 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**.

<Warning>
  **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](/webhooks/signing-and-retries#replay-protection). **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.
</Warning>

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

<Note>
  There is **no test marker.** A replay is indistinguishable from the original delivery by content — unlike the [Eagle Eye test webhook](/endpoints/eagle-eye#testing-your-receiver-—-post-/v1/eagle-eye/watches/watch_id/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.
</Note>

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

<Note>
  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](/webhooks/overview#self-service-event-history) where `delivery_failed` and `delivery_skipped` both read as `failed`.
</Note>

## Single attempt, real status

A replay makes **exactly one delivery attempt**. There is no retry ladder — the [5-attempt schedule](/webhooks/signing-and-retries#retry-policy-5-attempts) 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. |