Відтворення і «Машина часу»

Повторне надсилання знову запускає ту саму доставку за її розкладом повторних спроб. Відтворення створює нові доставки зі збережених подій. У панелі відтворення називається «Машина часу».

Що з цього вам потрібно

	Повторне надсилання доставки	Відтворення («Машина часу»)
Працює з	Однією наявною доставкою	Збереженими подіями за проміжок часу
Ідентифікатор доставки	Зберігається	Новий
Порядковий номер	Зберігається	Новий, тож доставка стає в чергу за живим трафіком
Idempotency-Key	Зберігається	<event id>-<endpoint id>
Первісна доставка	Знову йде в роботу	Лишається недоторканою
Коли потрібно	Одна доставка не пройшла, а отримувача вже виправлено	Отримувач втратив дані або новому ендпоінту потрібна історія

Повторне надсилання однієї доставки

POST /api/v1/deliveries/{id}/replay повертає доставку в PENDING і дає їй ще 3 спроби; першу Railhook надсилає одразу. Відповідь 202. Лічильник та історія спроб зберігаються, тож нові спроби нумеруються після старих, а інтервали беруться з того кроку розкладу, до якого доставка вже дійшла. Доставку, яка вже пройшла успішно, Railhook відхиляє, а доставку, спроба якої саме триває, відхиляє з 409, доки спроба не завершиться.

Параметри запиту:

Параметр	Дія
dryRun=true	Нічого не надсилає. Повертає цільовий URL, тип події, вміст, Idempotency-Key, який було б надіслано, попередні спроби й план: WILL_SEND; SKIP, якщо доставка вже пройшла успішно; або BLOCKED, якщо ендпоінт вимкнено.
fromAttempt=N	Замість 3 спроб дає доставці стільки, скільки в неї лишалося від спроби N: максимальна кількість спроб мінус N-1. N має бути від 1 до кількості вже зроблених спроб.

Використовуйте fromAttempt, коли 3 спроб замало, наприклад, якщо отримувач лежав кілька годин: fromAttempt=1 повертає весь розклад.

Щоб повторно надіслати багато доставок одразу, скористайтеся POST /api/v1/deliveries/bulk-replay зі списком до 1000 deliveryIds або з projectId, фільтрами status і endpointId та limit до 5000. Без status повторно надсилаються лише доставки, які впали або потрапили в «Недоставлені повідомлення». Доставку, яка вже пройшла успішно або спроба якої саме триває, Railhook завжди пропускає. У відповіді видно, скільки доставок надіслано повторно, скільки пропущено і чи знайшлися ще доставки понад ліміт.

Полишені доставки також можна повторити з «Недоставлених повідомлень»: див. Повторні спроби та недоставлені повідомлення.

Відтворення подій за проміжок часу

1. Спершу оцініть обсяг. POST /api/v1/projects/{projectId}/replay/estimate приймає те саме тіло, що й відтворення, і нічого не створює. Він повертає кількість подій і активних підписок (зокрема з шаблонами), що збігаються, кількість доставок, які буде створено, і попередження, якщо проміжок завеликий. Оцінка не застосовує правила, тож через правило з DROP або ROUTE реальне число буде іншим.

   curl -X POST "$RAILHOOK_URL/api/v1/projects/$PROJECT_ID/replay/estimate" \
     -H "X-API-Key: $API_KEY" \
     -H "Content-Type: application/json" \
     -d '{"fromDate":"2026-09-01T00:00:00Z","toDate":"2026-09-02T00:00:00Z","eventType":"order.completed"}'

2. Запустіть відтворення через POST /api/v1/projects/{projectId}/replay з тим самим тілом. fromDate і toDate обов’язкові; eventType, endpointId і sourceStatus звужують вибірку. Відповідь 201 із сесією.

3. Стежте за сесією через GET /api/v1/projects/{projectId}/replay/{sessionId} або зупиніть її через POST /api/v1/projects/{projectId}/replay/{sessionId}/cancel.

Відтворення спрямовує кожну збережену подію так само, як щойно надіслану: за активними підписками, що збігаються з її типом (зокрема з шаблонами на кшталт order.*), і за поточними правилами проєкту. Правило з DROP скасовує відтворення цієї події, дія ROUTE додає свій ендпоінт, а дія TRANSFORM замінює трансформацію підписки. Подію, яка перевищила б ліміт розгалуження, не відтворюють для жодного ендпоінта, і вона рахується як помилка сесії. З endpointId створюються лише доставки на цей ендпоінт.

Упорядковані ендпоінти отримують нові порядкові номери, тож відтворені доставки чекають за живими, а не конфліктують із ними.

Обмеження	Значення
Одночасних сесій відтворення на проєкт	2
Подій в одній сесії	REPLAY_MAX_EVENTS_PER_SESSION, типово 500000

Під час відтворення Idempotency-Key змінюється

Idempotency-Key відтвореної доставки дорівнює <event id>-<endpoint id>, тож не збігається з ключем, з яким надіслали первісну подію. Отримувачу, який мусить розпізнавати відтворення, варто відкидати дублікати за власним бізнес-ідентифікатором або за X-Event-Id.

Відтворення вхідних вебхуків

Вхідні події можна відтворити на всі призначення їхнього джерела:

• Одна подія: POST /api/v1/projects/{projectId}/incoming-events/{id}/replay.
• Багато подій: POST /api/v1/projects/{projectId}/incoming-events/bulk-replay з обов’язковим sourceId і або списком eventIds, або проміжком from і to; за потреби з фільтром verified та обмеженням maxEvents.

Кожне відтворення створює нові пересилання, які знову починаються зі спроби 1.