# Webhook Replay and Retrieve API V3 — Developer Guide

## 1. Overview

The Webhook Replay and Retrieve API lets you re-read the stream of webhook events Sprinklr already dispatched for a subscription over a given time window, and to retrieve the events that failed delivery. Use it to recover from an outage on your listener, to backfill events your consumer dropped, or to audit what Sprinklr actually sent.

The V2 documentation describes three use cases for this API family[doc:turn1doc3]:

- **Webhook Replay** — replay the stream of webhooks for a given time duration.
- **Cursor API** — fetch and replay the next set of data.
- **Retrieve Failed Webhooks** — retrieve failed webhooks for a subscription in a given time.


### 1.1 Operations

| # | Purpose | Method | Path |
| 1 | Replay webhook payloads from persisted dispatched webhook details | `POST` | `/webhookReplay`|
| 2 | Retrieve failed webhook events | `POST` | `/webhookReplay` |
| 3 | Fetch the next webhook replay page by cursor | `GET` | `/webhookReplay?cursor=` |

### 1.2 Prerequisites

- A webhook subscription must already exist; you replay **per `subscriptionId`**. Use the Webhook Subscription APIs to create or list subscriptions.
- **The API must be enabled for your environment.** *"Please reach out to your Success Manager or Sprinklr Support to get Webhook Replay API's enabled for your environment."*[doc:turn1doc1]


### 1.3 Retention

> **Failed webhooks are available for retrieval for 7 days.** Requests for `statuses: ["FAILED"]` with a `startTime` older than 7 days will not return those events. No retention period is stated anywhere for **non-failed** replay data.


## 2. Base URLs and environments

```
https://api3.sprinklr.com/{env}/api/v3
```

Replace `{env}` with your environment identifier (`prod0`, `prod2`, `prod11`, and so on). The list of environments and their identifiers is on the [Sprinklr APIs](https://dev.sprinklr.com/apis) page of the developer portal.

Full endpoint URLs used in this guide:

```
POST https://api3.sprinklr.com/{env}/api/v3/webhookReplay
GET  https://api3.sprinklr.com/{env}/api/v3/webhookReplay?cursor={cursor}
```

## 3. Authentication and common headers

All API calls are authenticated with OAuth 2.0. See [Developer Tools in Sprinklr](https://www.sprinklr.com/help/articles/developer-tools/developer-tools-in-sprinklr/692e8b39f0afa271d18a5929) for API key and secret generation, and the Authorize flow.

| Header | Value | Purpose | Required on |
|  --- | --- | --- | --- |
| `Authorization` | `******` | Credential used by the API to authenticate a user with the server | All requests |
| `Key` | `{{apiKey}}` | API key that authenticates the application with the server | All requests |
| `Content-Type` | `application/json` | Declares the request body media type | `POST`, `PUT`, `PATCH` |
| `Accept` | `application/json` | Determines the acceptable response type from the server | All requests |


## 4. Replay and retrieve operations

### 4.1 `POST /api/v3/webhookReplay` — Replay webhook payloads

Replays the stream of webhooks dispatched for a subscription within a time window. If more data exists than `size` allows, the response carries a `cursor` you pass to §4.3 to page forward.

**Endpoint**

```
POST https://api3.sprinklr.com/{env}/api/v3/webhookReplay
```

| Parameter | Required | Description | Type |
|---|---|---|---|---|
| `subscriptionId` | Required | Webhook Subscription Id | `string` |
| `startTime` | Required | The time from which you want to replay webhook. | `integer` (`int64`) Epoch |
| `endTime` | Required | The time to which you want to replay webhook.| `integer` (`int64`) Epoch |
| `size` | Required | The number of webhooks you want to fetch in one request.| `integer` (`int32`) |
| `statuses` | Optional | Specifies the webhook status values to filter in the response. Use this parameter to fetch only webhooks that match the selected status. Supported values: Active, Inactive | `array` of `string`|

**Example request** (illustrative example, generated from the documented schema; credentials are placeholders)

```bash
curl --location 'https://api3.sprinklr.com/{env}/api/v3/webhookReplay' \
  --header 'Authorization: ******' \
  --header 'Key: {apikey}' \
  --header 'Content-Type: application/json' \
  --header 'Accept: application/json' \
  --data '{
    "subscriptionId": "66bcba43c4470365a3037e45",
    "startTime": 1672642271000,
    "endTime": 1780383071000,
    "size": 10,
    "statuses": ["ACTIVE", "INACTIVE"]
  }'
```

**Example response** (illustrative example; payloads truncated)

```json
{
  "data": {
    "results": [
      "{\"id\":\"60a4e34aeb8f1e2030704a8a\",\"type\":\"message.created\",\"payload\":{ ... },\"eventTime\":1621418825965,\"subscriptionDetails\":{\"subscriptionId\":\"60a4e334db614859a3d2524f\"}}",
      "{\"id\":\"60a4e34a0e2bec6ac70a8b79\",\"type\":\"message.created\",\"payload\":{ ... },\"eventTime\":1621418826496,\"subscriptionDetails\":{\"subscriptionId\":\"60a4e334db614859a3d2524f\"}}"
    ],
    "cursor": "60a50efebc622348f58a975f"
  },
  "errors": []
}
```

### 4.2 `POST /api/v3/webhookReplay` — Retrieve failed webhook events

Same endpoint, same schema. Setting `statuses` to `["FAILED"]` retrieves the webhooks that failed delivery for the subscription in the given window, rather than replaying the full stream.

**Body parameters**

| Parameter | Required | Description | Type |
|  --- | --- | --- | --- |
| `subscriptionId` | Required | Id of the webhook subscription | String |
| `startTime` (in milliseconds) | Required | The starting time from when you want to analyze webhook statuses | Integer |
| `endTime` (in milliseconds) | Required | The end time up till when you want to analyze webhook statuses | Integer |
| `size` | Optional | The expected size of the response | Integer |
| `statuses` | Required | The state of the webhook case. For example: FAILED or DELIVERED | String |


**Example request** (illustrative example; credentials are placeholders)

```bash
curl --location 'https://api3.sprinklr.com/{env}/api/v3/webhookReplay' \
  --header 'Authorization: ******' \
  --header 'Key: {apikey}' \
  --header 'Content-Type: application/json' \
  --header 'Accept: application/json' \
  --data '{
    "subscriptionId": "66bcba43c4470365a3037e45",
    "startTime": 1735800671000,
    "endTime": 1780383071000,
    "size": 10,
    "statuses": ["FAILED"]
  }'
```

**Example response** (illustrative example; payload truncated)

```json
{
  "data": {
    "results": [
      "{\"id\":\"624427519d643560ccbc0a15\",\"type\":\"draft.created\",\"payload\":{ ... },\"eventTime\":1648633681578,\"subscriptionDetails\":{\"subscriptionId\":\"6230a3b4215cc62878dbfe58\"}}"
    ],
    "cursor": "624d6111811f63194273b055"
  },
  "errors": []
}
```

> **Remember the 7-day window.** Failed webhooks are only retrievable for 7 days. A `startTime` outside that window returns nothing for `FAILED`, without necessarily raising an error.


### 4.3 `GET /api/v3/webhookReplay?cursor=` — Fetch the next page

When the replay or retrieve response contains a non-null `cursor`, more data is available. Pass that cursor back to fetch the next page. Repeat until the response no longer returns a cursor.

**Endpoint**

```
GET https://api3.sprinklr.com/{env}/api/v3/webhookReplay?cursor={cursor from previous call}
```

**Query parameters**

| Parameter | Required| Description | Type |
|---|---|---|---|---|
| `cursor` | Required` | Webhook Cursor from Webhook Replay API call. | String |

**Example request** (illustrative example; credentials are placeholders)

```bash
curl -X GET \
  'https://api3.sprinklr.com/{env}/api/v3/webhookReplay?cursor=60a507a2bc622348f58a8023' \
  -H 'Authorization: ******' \
  -H 'Key: {apikey}' \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json'
```

## 6. Reference tables

### 6.1 Status values named across sources

No `enum` is declared in `sprinklr-v3.yaml`. This is the union of values named in the sources, not a confirmed list.

| Value | Named in | Context |
|  --- | --- | --- |
| `ACTIVE` / Active | V2 Replay page ("Active"), Jira cURL (`"ACTIVE"`) | Replay filter |
| `INACTIVE` / Inactive | V2 Replay page ("Inactive"), Jira cURL (`"INACTIVE"`) | Replay filter |
| `FAILED` | V2 Retrieve Failed page, Jira cURL, Jira description | Failed-event retrieval |
| `DELIVERED` | V2 Retrieve Failed page ("For example: FAILED or DELIVERED") | Failed-event retrieval |


### 6.2 Schema quick reference

`WebhookReplayRequest` (request body for `POST /webhookReplay`) — no `required` list declared:

| Property | Type |
|  --- | --- |
| `subscriptionId` | `string` |
| `startTime` | `integer` (`int64`) |
| `endTime` | `integer` (`int64`) |
| `statuses` | array of `string` |
| `webhookTypes` | array of `string` |
| `eventId` | `string` |
| `size` | `integer` (`int32`) |


## 7. Use cases

### 7.1 Recover from a listener outage

Your endpoint was down from 09:00 to 11:30. Call `POST /webhookReplay` with the subscription id and `startTime`/`endTime` set to that window in epoch milliseconds, then page with the cursor until no cursor is returned.

### 7.2 Retrieve everything that failed delivery yesterday

Call `POST /webhookReplay` with `statuses: ["FAILED"]` and a 24-hour window. Stay inside the 7-day retention limit (§1.3).

### 7.3 Reconcile delivered against failed

Run the same window twice — once with `statuses: ["FAILED"]` and once with `statuses: ["DELIVERED"]` — and diff the `id` values to find events your system never processed. `DELIVERED` is named only as an example on the V2 page; verify it is accepted before relying on this.

### 7.4 Page through a large window

```
POST /webhookReplay   → { "data": { "results": [...], "cursor": "C1" }, "errors": [] }
GET  /webhookReplay?cursor=C1 → { "data": { "results": [...], "cursor": "C2" }, "errors": [] }
GET  /webhookReplay?cursor=C2 → { "data": { "results": [...] }, "errors": [] }   ← no cursor: done
```

### 7.5 Backfill a new downstream consumer

Point a fresh consumer at a historical window and replay the stream into it, rather than waiting for new live events.

### 7.6 Audit what Sprinklr actually sent

Replay a window and compare the `eventTime` and `payload` of each event against your own ingestion log to prove or disprove a delivery gap.

### 7.7 Narrow a replay to one event type

Send `webhookTypes` alongside the time window to limit the replay. **Unverified** — this field is present in the V3 schema but has no description and no example. Confirm before use.

### 7.8 Re-fetch a single known event

Send `eventId` to target one dispatched event. **Unverified**, as above.