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 ParametersExpand Collapse

wh: string

Body ParametersJSONExpand Collapse

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.

formatint32

since: optional string

Replay events at or after this instant.

formatdate-time

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.

formatdate-time

ReturnsExpand Collapse

created: number

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

formatint32

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.

formatint32

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.

formatint32

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.

formatint32

Replay past events to a webhook endpoint

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

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

Returns Examples

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