---
title: "Resend failed deliveries to an endpoint"
method: POST
path: "/api/v1/trigger-delivery/endpoints/{endpoint_id}:recover"
tags: ["Triggers"]
---

# Resend failed deliveries to an endpoint

`POST /api/v1/trigger-delivery/endpoints/{endpoint_id}:recover`

## Request

- Base URL: `https://$SCALEKIT_ENVIRONMENT_URL`
- URL: `https://$SCALEKIT_ENVIRONMENT_URL/api/v1/trigger-delivery/endpoints/{endpoint_id}:recover`
- Auth: OAuth 2
  - Client credentials
  - Token URL: `https://$SCALEKIT_ENVIRONMENT_URL/oauth/token`
- TypeScript: <https://skmtc.dev/scalekit/apis/scalekit-api-reference/docs/api/v1/trigger-delivery/endpoints/:endpoint_id:recover/post.ts> (a function with typed inputs; its response is checked against the schema)

Starts a recovery that resends every trigger event whose delivery to one endpoint failed within a time window. Use this endpoint once your endpoint is healthy again after an outage, instead of resending each failed delivery with BatchResendTriggerDeliveries. Pass the delivery endpoint ID in the path, and `since` and optionally `until` in the body. The recovery covers events with a failed attempt to this endpoint from `since` up to, not including, `until`. It skips an event that also has a successful attempt to this endpoint within the window, and it never sends an event that was not already sent to this endpoint. The window is at most 14 days; omit `until` to recover up to the present. The recovery runs in the background after this call returns, so the response confirms that it started, not that anything was delivered. Each recovered event gets a new attempt, which appears in ListTriggerDeliveriesByEndpoint and ListTriggerDeliveryAttemptsByMessage like any other. One call recovers at most 10,000 events and stops there without reporting it: when more may have failed, cover the period with several calls over narrower windows. Recovery progress cannot be read through the API. `task_id` identifies this recovery in Scalekit's logs for support, and there is no endpoint to poll it. Not idempotent: calling again re-queues every event that is still failed, and a second call made before the first finishes can queue a second attempt for the same event. Returns the recovery's task_id and its status when this call returned. The event payload is never returned.

## Path parameters

- `endpoint_id` string, required

## Request body

- TriggerServiceRecoverTriggerDeliveriesBody: The endpoint and the window to recover failed deliveries for. The window must not start or end in the future, must end after it starts, and must span at most 14 days; a window that breaks a rule is refused with a 400 that names the rule.
  - `since` string, date-time, required: Start of the window, inclusive: events with a failed attempt to this endpoint at or after this instant are recovered. Must not be in the future, and must be at most 14 days before `until`, or before now when `until` is omitted.
  - `until` string, date-time: End of the window, exclusive. Omit it to recover up to now. Must be after `since`, must not be in the future, and must be at most 14 days after `since`.

## Response `200`

The recovery started; includes its task_id and its status when this call returned. Events are resent in the background after this response. In the rare case that the recovery was accepted without an identifier, task_id and status are empty; the recovery still runs

- TriggersRecoverTriggerDeliveriesResponse: A recovery that has started. Its outcome is not reported: the recovery runs in the background, and no record of it can be read back through the API.
  - `status` string: The recovery's state when this call returned. `running` in practice: the recovery continues after the response, and its later state is not reported.
  - `task_id` string: Identifies this recovery in Scalekit's logs; quote it when contacting support. It cannot be looked up or polled through the API.

## Other responses

- `400`: Invalid request, no recovery started - `endpoint_id` is not an endpoint ID (`ep_` followed by 1 to 64 letters or digits); `since` is missing, or `since` or `until` is not a valid timestamp; `since` is in the future; `until` is in the future; `until` is not after `since`; or `until` is more than 14 days after `since`, measured to now when `until` is omitted, so the period must be split into several calls
- `404`: Not found - the endpoint is not one of this environment's trigger delivery endpoints, or Triggers is not enabled for the environment. No recovery started
- `429`: Too many requests - this environment has started too many recoveries in a short period, or requests are being refused for volume. No recovery started; retry after a short wait
- `500`: Internal error - the recovery was not confirmed. Either it could not be started, or the request timed out or failed after it may already have been accepted, in which case the error message says it may be running. In that case look for new manual attempts with ListTriggerDeliveriesByEndpoint before calling again, because a second call can queue a second attempt for the same event

## Changes

- **2026-10-30** `f47f1022d844`: 1 info
  - endpoint added

[Operation history](https://skmtc.dev/scalekit/apis/scalekit-api-reference/changes/api/v1/trigger-delivery/endpoints/:endpoint_id:recover/post.md)

---

[API](https://skmtc.dev/scalekit/apis/scalekit-api-reference.md) - [All operations](https://skmtc.dev/scalekit/apis/scalekit-api-reference/llms.txt) - [OpenAPI document](https://skmtc.dev/scalekit/apis/scalekit-api-reference/revisions/f47f1022d844?raw)
