Re-send a past delivery
Creates a NEW delivery row carrying the ORIGINAL payload bytes and attempts it immediately. So the envelope’s id is unchanged — it names the event, and you should dedupe on it if you already processed it — while X-Triggr-Delivery-Id and the returned deliveryId are new, naming this new delivery row. The response reports that first attempt AND the new delivery row, so you can prepend it to a list without reconstructing it. The original delivery is left as history. A delivery that is still pending is refused (400): it is already being retried.
Authorizations
Organisation API key. Scoped operations carry x-triggr-scope; the scopes themselves are described in x-triggr-scopes.
Headers
OPTIONAL — omit it and this operation behaves exactly as it always has. A unique value (a UUID) you choose per request. A retry with the same key and the same method, path and body within 24 hours gets the first response replayed (status and body, with Idempotent-Replayed: true) instead of running again; the same key with a different request is refused with 422. A 5xx is not stored, so that retry runs. A one-time credential is never stored: on a replay any secret is null, with an idempotentReplayNote explaining it.
1 - 255Response
OK
A redelivery's first attempt plus the NEW delivery row it created — prepend delivery to your list rather than reconstructing it
The NEW delivery row's id (also delivery.id). The event id inside the re-posted envelope is still the original's
pending, delivered, failed, unknown 
