Исходная схема
Из каких узлов состоит проверка
Seed отправляет вопрос об артикуле или номере заказа, но после него нет waitInput или другого ожидания. Следующий setVariable сразу записывает в order_article буквальную строку {{input}}, затем apiCall делает GET-запрос по адресу https://your-api.com/orders/{{order_article}}. Граф продолжает выполнение без введённого пользователем идентификатора, поэтому это не рабочая проверка статуса.
После apiCall seed показывает order_article и {{last_http_body}}, ставит тег api_order_check и завершается. В нём нет веток для неверного идентификатора, отсутствующего заказа, отказа в доступе или недоступности поставщика. URL и bearer-токен YOUR_API_TOKEN — заглушки, а не рабочие данные; они не должны попадать в пользовательский текст или репозиторий.
До публикации обязательно добавьте supported-ноду ожидания ввода, валидацию формата и проверку того, что пользователь вправе видеть конкретный заказ. Затем сопоставьте разрешённые поля ответа API с отдельными сообщениями для успеха, пустого результата и ошибки. Только такая последовательность может безопасно показывать статус в чате.
- После вопроса добавлена supported-нода waitInput, которая сохраняет введённый идентификатор.
- Определите, что именно вводит пользователь: номер заказа, артикул или иной идентификатор.
- Получите документированный URL, метод, авторизацию и ожидаемые коды ответа у владельца API.
- Проверьте формат и право пользователя видеть заказ до apiCall.
- Сопоставьте разрешённые поля ответа с отдельными сообщениями успеха, пустого результата и ошибки.
Пример диалога
Идентификатор и владелец
Добавьте ожидание, проверку формата и доступа
Первая обязательная доработка — поставить waitInput после вопроса и сохранить ответ в переменную идентификатора. Не используйте setVariable со строкой {{input}} как замену ожиданию: компилятор передаёт значение этой ноды буквально. Сообщение человека должно появиться в контексте только после поддерживаемой ноды ожидания.
После ожидания задайте формат: длину, допустимые символы и нормализацию. Не передавайте в URL всё, что пришло в чат, без валидации и кодирования, особенно при специальных символах. Номер заказа или артикул не всегда подтверждает владельца, поэтому до apiCall нужен согласованный механизм проверки связи пользователя с заказом.
Если API возвращает персональные данные, адрес, телефон, состав корзины или статус оплаты, не раскрывайте их только по известному номеру. При неверном вводе, отсутствии права или недоступности API дайте нейтральное сообщение и рабочий путь в поддержку. Не позволяйте ответу сообщать, существует ли чужой заказ, если это помогает перебирать идентификаторы.
Добавьте ожидание идентификатора
Поставьте waitInput после вопроса и сохраните ответ в отдельную переменную. Только затем переходите к проверке формата и apiCall.
Проверьте право на просмотр
Добавьте до apiCall механизм, который связывает пользователя бота с заказом, если ответ содержит закрытые сведения.
Обработайте неверный ввод
Валидируйте формат до запроса и подготовьте повторный вопрос без технических деталей и без показа содержимого системной ошибки.
Подключение внешнего сервиса
Замените заглушки на согласованный контракт
Адрес https://your-api.com/orders/{{order_article}} в сиде — пример формы маршрута. У поставщика может быть другой домен, путь, параметр запроса, версия API, метод или способ подписания. Не меняйте строку на предполагаемый адрес из поисковой выдачи и не используйте название маркетплейса как доказательство совместимости. Возьмите конечную точку из документации или у владельца интеграции и проведите отдельную техническую проверку доступа.
Bearer-токен YOUR_API_TOKEN тоже является заглушкой. Рабочие секреты нельзя размещать в сообщениях, статьях, репозитории или полях, которые могут быть видны редактору без нужного доступа. Храните их в защищённой конфигурации по правилам вашего контура и выдавайте минимально необходимые разрешения. Если конструктор не позволяет безопасно передать секрет, подключение нужно проектировать через подходящий серверный слой, а не обходить ограничение.
Согласуйте ограничения API: частоту запросов, время ответа, повторы, коды ошибок и поля результата. У пользователя не должно создаваться впечатление, что бот проверил заказ, когда внешний вызов завершился ошибкой или вернул неполный ответ. Исходный шаблон не содержит обработки этих состояний, поэтому добавьте ветки до публичного запуска.
Формат сообщения
Показывайте статус, а не сырое тело ответа
{{last_http_body}} удобно для демонстрации, потому что показывает последнее тело HTTP-ответа. В рабочем диалоге оно может оказаться длинным, техническим или содержать поля, которые не предназначены для пользователя. Лучше определить небольшой список понятных значений: например, статус, дата ожидаемого действия и безопасный номер заказа. Способ извлечения этих полей зависит от формата внешнего API и возможностей вашего сценария.
Подготовьте отдельные ответы как минимум для успешного поиска, неизвестного номера, временной ошибки и ситуации, когда нужна дополнительная проверка владельца. Не пишите пользователю код ошибки, внутренний адрес, токен или полный ответ поставщика. Для недоступного API достаточно сказать, что данные не удалось получить, и предложить повторить запрос позднее либо обратиться в рабочую поддержку, если она есть.
Тег api_order_check полезен как техническая метка того, что путь дошёл до конца шаблона. Он не доказывает, что заказ найден, что ответ был успешен или что пользователь увидел корректный статус. Для таких различий создайте отдельные события или теги в добавленных ветках с точным смыслом. Это поможет не смешивать успешные проверки и ошибочные попытки в одном сегменте.
- Публичное сообщение содержит только разрешённые и понятные поля.
- Ошибочные ответы не раскрывают устройство внешней системы.
- Успешный, пустой и ошибочный результаты имеют разные следующие действия.
- Тег api_order_check не используется как подтверждение успешного поиска.
Перед публикацией
Проверьте сценарий на безопасных данных
Начните с тестового заказа или разрешённого тестового идентификатора, который возвращает заранее известный результат. Пройдите весь путь: запрос, сохранение order_article, вызов API, подготовленное сообщение и тег. Проверьте, что адрес принимает именно тот формат, который пользователь вводит, и что в логах не появляются секреты. Не используйте настоящие чужие заказы для подбора работающего запроса.
Затем смоделируйте безопасным способом неправильный номер, отказ в доступе, задержку и ошибку внешнего сервиса. Пользовательские сообщения должны оставаться понятными, а сценарий не должен выдавать сырой ответ из {{last_http_body}}, если он содержит служебные данные. Если интеграция влияет на поддержку, заранее договоритесь, кто видит сбои и каким способом их разбирает.
После запуска периодически сверяйте ответы бота с разрешённым источником данных и обновляйте контракт при изменениях API. Название поставщика, URL и формат ответа могут меняться независимо от шаблона. Отдельная проверка интеграции нужна после таких изменений; текстовая статья и примерный сценарий не заменяют её.