## Replay past events to a webhook endpoint

**post** `/v1/webhook_endpoints/{wh}/replay`

Deliver past events to this endpoint.

An endpoint receives events that happen while it exists. Register one on day 5
and days 1 to 4 are not waiting for it. This is how you fetch them: name the
events, or a time range, and every matching event with no delivery to this
endpoint gets one.

**A replayed delivery arrives behind live traffic, not in front of it.** Within a
chat, deliveries arrive in order and each waits for the one before it. A replay of
an old event would otherwise sort ahead of everything current and hold up the
traffic you are serving right now, so replays queue after live work instead. The
in-order guarantee still holds for live traffic; a replay is the one thing that
arrives out of its original place, by design.

**Sending the same request twice creates nothing the second time.** Each call gets
its own `request_id`, so two calls are two requests, but a delivery that already
exists is not made again. The response counts `created` and `skipped` separately
so a retry after a timeout tells you what actually happened.

**A range larger than `max` is refused, not trimmed.** A trimmed replay looks like
a finished one, and you would believe you had caught up. Narrow the range or raise
`max`, then send it again.

**It follows this endpoint's `enabled_events`.** An event type this endpoint does
not subscribe to is not in scope for its replay, the same way it would not have
been delivered live. Narrow or widen the subscription to change what a replay can
reach. An endpoint that is disabled, or whose brand's agent is paused, answers
`409 webhook_endpoint_not_receiving` rather than reporting nothing to do.

Every delivery this creates carries `replay_of` set to the `request_id`, so you can
tell a replay from live traffic on arrival.

### Path Parameters

- `wh: string`

### Body Parameters

- `event_ids: optional array of string`

  Replay exactly these events, at most 1000 per call. Send this or a range,
  not both. They ask two different questions, and answering the wrong one is
  worse than refusing.

- `max: optional number`

  Most events one call may replay from a range. 1-1000, default 500. Send
  it with a range, not with `event_ids`: a list you named is already its
  own bound, so a `max` beside it would have nothing to do.

- `since: optional string`

  Replay events at or after this instant.

- `type: optional string`

  Narrow a range to one event type, e.g. `message.received`. It narrows;
  it does not select. Sent on its own it is refused, because a bare type
  would replay your whole history of that type.

- `until: optional string`

  Replay events at or before this instant.

### Returns

- `created: number`

  Deliveries created. These are queued behind whatever live traffic the chat has.

- `not_found: number`

  Ids you named with no event of yours behind them: a typo, or an event old
  enough to have been swept. Always 0 for a range.

- `not_subscribed: number`

  Events you named that this endpoint does not subscribe to, so they were never
  in scope for it. Always 0 for a range, where the subscription narrows the
  window rather than rejecting something you pointed at.

- `request_id: string`

  This request's id, `rpl_…`. Every delivery it created carries it as `replay_of`.

- `skipped: number`

  Events skipped because this endpoint already has a delivery for them.

### Example

```http
curl https://messages.api.linqapp.com/v1/webhook_endpoints/$WH/replay \
    -H 'Content-Type: application/json' \
    -H "Authorization: Bearer $LINQ_AMB_API_KEY" \
    -d '{}'
```

#### Response

```json
{
  "request_id": "rpl_9c2f1a7b",
  "created": 128,
  "skipped": 4,
  "not_subscribed": 0,
  "not_found": 0
}
```