Стратегия резервного варианта

В случае недоступности сервиса вебхуков рекомендуется реализовать резервный механизм, чтобы ваше приложение могло получить результат процесса в ожидаемое время ответа.

Как это работает

Вебхук является основным механизмом доставки результатов. Однако следующие сигналы следует рассматривать как дополнительные триггеры для активного получения результата через GET /client/v1/process/{processId}:

Сигнал	Канал	Что предоставляет
Обратный вызов onFinish	SDK Web / WebMobile	Сигнал завершения сценария — без результата
Перенаправление callbackUri	Все остальные каналы	Только URL-перенаправление — без результата

предупреждение

Ни onFinish, ни callbackUri не передают результат процесса напрямую. Это лишь сигналы завершения сценария. Ваш бэкенд обязан сопоставить полученный id (или перенаправление) с ранее сохранённым processId и вызвать GetProcess для получения фактического результата.

Рекомендуемый порядок действий

После получения сигнала завершения сценария ваш бэкенд должен вызвать GET /client/v1/process/{processId} и проверить результат в следующем порядке:

1. Убедиться, что state = PROCESS_STATE_FINISHED
2. Оценить поле result и применить свои бизнес-правила

Это гарантирует, что временная недоступность вебхуков не приведёт к потере результатов процессов.