Ответы и ошибки вебхука в AI Flowi Workflow: как они работают?

Ответы и ошибки вебхука: выберите режим ответа для каждого принимаемого метода Universal Webhook. Используйте From Flow и компонент Webhook Response, когда рабочий процесс должен задавать HTTP-статус и тело ответа. Протестированный сценарий передачи данных из вебхука в Google Sheets возвращал 200 после корректной записи, 422 при некорректных входных данных и 403 при отсутствующем или недействительном API-ключе. Сбой последующего компонента Google Sheets останавливал процесс и возвращал необработанную ошибку платформы в версии 1.9.2; до ветви с ответом, заданным в процессе, выполнение не доходило.

Опубликовано · Обновлено . Результаты проверки в рабочей среде: 8–9 октября 2026, AI Flowi Workflow 1.9.2.

Следуйте сценарию передачи данных из вебхука в Google Sheets и изучите его результаты тестирования в рабочей среде. Используйте версию с защитой от дублей, если отправители повторяют доставку.

Какой режим ответа выбрать?

Задайте режим ответа отдельно для каждого разрешённого HTTP-метода в Universal Webhook.

Режимы ответа согласно документации
РежимЧто получает отправитель
ImmediateНастроенный для метода ответ, пока процесс выполняется в фоновом режиме.
After ExecutionНастроенный ответ после завершения процесса.
From FlowОтвет от единственного компонента Webhook Response, срабатывающего на выполняемом пути после выполнения процесса.

Для From Flow на каждом выполняемом пути должен срабатывать ровно один компонент Webhook Response. В протестированном сценарии отдельные ответы об успехе и отклонении подключены к разным ветвям Verification Router. Отсутствие ответа на выполняемом пути или наличие нескольких таких ответов может привести к ошибке.

Test Endpoint фиксирует запросы без выполнения процесса. С его помощью нельзя проверить получение ответа From Flow после выполнения процесса. Проверяйте полный цикл запроса, записи и ответа через Production Endpoint с синтетическими данными.

Как задать HTTP-статус и тело ответа?

Выберите From Flow для метода вебхука, затем подключите выход ветви к Webhook Response.

Настройки Webhook Response
ВходДействие
Response BodyПодключите значение типа JSON или Message. Для объектов и массивов используется application/json; для обычного текста и скалярных значений — text/plain.
HTTP StatusЗадайте код состояния по умолчанию, например 200 для успешной записи или 422 для отклонённых входных данных в протестированном сценарии.
Content TypeЗадайте тип содержимого явно или оставьте поле пустым для автоматического определения.
Additional Response HeadersУкажите дополнительные HTTP-заголовки.
Response DefinitionУкажите динамические значения body, status_code, content_type или headers.

Значение body в Response Definition заменяет подключённый Response Body; статус и тип содержимого заменяют соответствующие значения настроенных полей. При совпадении имён заголовков настроенные Additional Response Headers имеют приоритет над заголовками в Response Definition.

Что показали тесты кодов 200, 422 и 403?

Эти результаты относятся к проверенному сценарию передачи данных из вебхука в Google Sheets без использования модели, с POST, аутентификацией Platform API Key и режимом From Flow. Его протестировали в рабочей среде 8 октября 2026, затем импортировали в чистый процесс и протестировали повторно. Эти проверки повторили для версии с защитой от дублей 9 октября 2026 как в исходном процессе, так и в импортированной копии.

HTTP-ответы и результаты записи, проверенные в рабочей среде
ЗапросHTTP-ответВлияние на лист
Корректные входные данные с успешной аутентификацией200 после успешной записиДля нового события добавлена одна строка.
Отсутствующий email, числовое значение поля name, некорректный email или некорректный JSON422 из ветви отклонения при валидацииСтрока не добавлена.
Отсутствующий или недействительный Platform API Key403 при аутентификации платформой, до запуска процессаСтрока не добавлена.

Например, тест с отсутствующим email вернул HTTP 422 со следующим телом ответа валидации:

{"verified":false,"error":"Validation failed","details":["email is required and must be a valid address"]}

Эти статусы зависят от протестированной конфигурации. Они не означают, что каждый рабочий процесс использует такую же валидацию или такие же ответы. Аутентификация External Provider не тестировалась.

Что происходит при сбое последующего компонента?

Ограничение на указанную дату: AI Flowi Workflow 1.9.2, зафиксировано 8–9 октября 2026. Ошибка Google Sheets останавливает граф до выполнения последующего Webhook Response. В этой версии компоненты Sheets не имеют выхода ошибки для ветви обработки ошибок внутри процесса, а после сбоя шаблон ответа From Flow игнорируется.

Несуществующий Spreadsheet ID вернул HTTP 404 с необработанной ошибкой компонента в тесте Append Rows от 8 октября. Тесты Upsert Row от 9 октября показали такое же поведение с необработанной ошибкой 404 как в исходном, так и в импортированном процессе. Число строк на тестовом листе не изменилось. Предусмотренный ответ с кодом 502 получить не удалось.

Также наблюдался HTTP 500, когда скрытый запрос JQ терялся при выполнении, с сообщением JSON Query is required and cannot be blank. Оставляйте поле JQ Expression видимым. При зафиксированном поведении платформа возвращает код 404, если текст ошибки содержит «not found». Другие сбои могут возвращать 500 с необработанными подробностями ошибки. Не считайте такой 404 доказательством того, что сам URL вебхука отсутствует.

Добавление Webhook Response после узла Sheets не позволяет перехватить этот сбой. Чтобы при сбое электронной таблицы возвращать заранее заданный ответ, требуется изменение платформы, например выход ошибки у компонентов Google или очистка ошибок вебхука от внутренних подробностей.

Как избежать раскрытия необработанных ошибок конечным пользователям?

Не показывайте конечным пользователям ответ конечной точки дословно. Зафиксированная ошибка Sheets включала URL Google API и Spreadsheet ID. Перед запуском проверьте подключение Google, Spreadsheet ID и общий доступ; приложение, получающее ответ, должно показывать заранее заданное сообщение об ошибке для пользователя при неудачном запросе.

Сценарий с защитой от дублей преобразует успешный результат Sheets в {"status":"inserted"} или {"status":"duplicate"}, удаляя Spreadsheet ID, диапазон и поля Google из тела успешного ответа. Это преобразование не очищает ошибку компонента от внутренних подробностей, поскольку после ошибки Sheets оно не выполняется.

Как учесть повторные попытки отправителя?

Используйте протестированную версию с защитой от дублей, если отправители повторяют доставку. Более простой сценарий Append Rows добавлял ещё одну строку при второй идентичной доставке. Версия от 9 октября использует Upsert Row с ключом event_id: передавайте тот же идентификатор при повторных попытках доставки одного события и другой идентификатор для нового события.

Синтетический запрос без конфиденциальных данных для версии с защитой от дублей:

{
  "event_id": "example-event-001",
  "name": "Webhook Test",
  "email": "test@example.com",
  "request": "Synthetic test"
}
  • Последовательные доставки: первый запрос вставляет строку и возвращает 200 {"status":"inserted"}. Повторный идентификатор обновляет эту строку, возвращает 200 {"status":"duplicate"} и не добавляет вторую строку. При обновлении действует правило: последняя запись имеет приоритет.
  • Идентификатор: текст, переданный отправителем, длиной 1–100 символов, сохраняется дословно; сопоставление чувствительно к регистру, пробельные символы не обрезаются.
  • Область действия и срок хранения: один лист в одной электронной таблице; все отправители, записывающие в него, используют общее пространство ключей. Защита действует, пока строка сохраняет этот идентификатор. Нет срока истечения или отдельного журнала получения; удаление или изменение идентификатора позволяет выполнить ещё одну вставку.
  • Результаты проверки одновременной повторной доставки: 9 октября 2026 все пять одновременных запросов с одним event_id получили ответ 200 и записали 3 дополнительные строки на лист (15 → 18; строки с совпадающим событием 0 → 3). Этот рабочий процесс не защищён от конкурентного выполнения. Настройте отправителя на последовательную доставку или устраняйте дубли на последующих этапах. Upsert Row читает и записывает без блокировки. Существующие строки-дубли не объединяются. См. результаты повторной проверки надёжности.

Защита от дублей при последовательной доставке и обработка ошибок электронной таблицы, возвращаемых без изменений — отдельные задачи. Протестированная версия для повторной доставки всё ещё имеет описанное выше ограничение обработки сбоев в версии 1.9.2.

Что проверить перед запуском?

  1. Конфигурация: разрешите HTTP-метод отправителя, настройте аутентификацию и выберите режим ответа. В From Flow проверьте, что на каждом выполняемом пути срабатывает ровно один компонент Webhook Response. Оставляйте поля JQ Expression видимыми.
  2. Успешная запись: отправьте синтетические корректные данные на Production Endpoint. Проверьте HTTP 200, тело ответа и одну новую строку для нового события.
  3. Валидация: не передавайте email, передайте число в поле name, укажите некорректный email и отправьте некорректный JSON. В протестированном сценарии каждый случай возвращает 422 без добавления строки.
  4. Аутентификация: проверьте отсутствующий и недействительный Platform API Key. В протестированной конфигурации каждый случай должен возвращать 403 без добавления строки.
  5. Повторные попытки: последовательно повторите тот же event_id. Проверьте сначала inserted, затем duplicate, с одной строкой в итоге. Отправьте другой event_id с тем же телом и проверьте, что добавлена отдельная строка. Пакет из пяти одновременных доставок от 9 октября 2026 вернул 200 для всех запросов и добавил 3 строки для одного event_id. Настройте отправителя на последовательную доставку или устраняйте дубли на последующих этапах.
  6. Граничные значения идентификатора: в версии с защитой от дублей отсутствующий, null, числовой, пустой event_id и event_id длиной 101 символ должны возвращать 422 без добавления строки; корректный идентификатор длиной 100 символов должен возвращать 200 и добавлять одну строку.
  7. Сбой последующего компонента: используйте отдельный синтетический тестовый процесс с несуществующим Spreadsheet ID. Запишите фактический HTTP-статус и тело ответа, затем повторно считайте число строк на тестовом листе. Версия 1.9.2 возвращала необработанные ошибки 404; проверьте поведение развёрнутой у вас версии и сообщение приложения о сбое для пользователя.
  8. Импортированная копия: после импорта рабочего процесса без конфиденциальных данных настройте свой аккаунт Google, Spreadsheet ID и аутентификацию вебхука, затем повторите проверки.

Прочитайте обзор продукта AI Flowi Workflow и проверьте необходимое вам поведение при сбоях, прежде чем выбирать конфигурацию.

Universal Webhook · Webhook Response · Сценарий передачи данных из вебхука в Google Sheets · Результаты тестирования в рабочей среде · Настройка защиты от дублей и ограничения