Redeliver subscription events
Have you missed a webhook notification recently due to an outage? Tango API webhook subscribers are now able to request the system to redeliver past webhook notifications for up to three months. Subscription events older than three months are not retrievable. POST is the http method used to send data to the server. Replace {webhookId} with the unique identifier of the webhook.
Use the following endpoint to redeliver past subscription events for a specific webhook:
Endpoint | Purpose |
---|---|
POST /webhooks/{webhookId}/replay | To redeliver past subscription events |
The following path parameter is used to specify the unique identifier of the webhook for which you want to request the redelivery of past notifications:
Path params | Data type | Requirement | Description |
---|---|---|---|
webhookId | string | required | The specific event ID |
The following query parameters are used with this endpoint like this: POST {URI}/webhooks/{webhookId}/replay?fromRevision={integer}&&toRevision={integer}
. If you set fromRevision
to 0 and do not put any integer for toRevision
, all events are replayed. If fromRevision
= 0 and toRevision
= 1, the first two events will be replayed and so on:
Query params | Data type | Requirement | Description |
---|---|---|---|
fromRevision | number | required | The beginning revision number to be replayed. It is the starting point or version from which you want to replay webhook notifications. It's particularly useful if you want to replay notifications starting from a specific revision or change. For example, fromRevision=67890 specifies that you want to replay notifications starting from revision 67890. |
toRevision | number | optional | The ending revision number (up to and including) to be replayed. If null, replay all event notifications from the fromRevision to the current (or latest). This can be useful if you want to replay notifications up to a specific revision or change such as toRevision=78901 . |
The following sample response is returned with a successful 200 Ok.
-- Response
{
Here's an example of 404 Not Found error message:
{
"timestamp": "2025-05-06T16:28:00.849211031Z",
"requestId": "12f231cc-6e36-42c9-9950-d971ff550f51",
"path": "/raas/v2/webhooks/200b8d5-292d-49c2-a542-57b6773d61e2/replay",
"httpCode": 404,
"httpPhrase": "Not Found"
}
The possible response codes for this endpoint are as follows. For details, see i18nkey codes and their error messages:
- 200 OK
- 400 Bad Request
- 404 Not Found
- 422 Unprocessable Entity
Updated about 23 hours ago