HTTP

Ноди секції HTTP використовуються для інтеграції сценарію із зовнішніми сервісами. HTTP Request виконує вихідний HTTP-запит під час виконання сценарію, а HTTP Webhook запускає новий сценарій зовнішнім HTTP POST.

1. HTTP Request (Http запит)

HTTP Request (HttpRequest) виконує outbound HTTP-запит до CRM, ERP, власного backend або іншого API, чекає відповідь і перетворює її на змінні для наступних нод.

Використовуйте HTTP Request, коли потрібно:

отримати дані із зовнішнього API;
відправити дані в CRM, ERP або власний backend;
передати значення зі змінних сценарію через headers або JSON body;
перевірити результат HTTP-запиту в наступній Condition;
використати відповідь API в наступних нодах або повернути її через JSON output.

Налаштування

Поле	Значення
`Url`	Повна адреса endpoint; підтримує `#var` і `{{ JS }}`
`Method`	`Get=0`, `Post=1`, `Put=2`, `Patch=3`, `Delete=4`
`Headers`	Dictionary заголовків; values підтримують `#var` і `{{ JS }}`
`BodyTemplate`	UTF-8 `application/json` body; підтримує `#var` і `{{ JS }}`
`TimeoutMs`	Timeout відповіді в мілісекундах. Не задано, `0` або від'ємне значення використовує backend default 100 с. Максимум 30 хвилин. Працює у sync та async режимах
`AsyncRequest`	Виконує запит у фоні без очікування відповіді; за замовчуванням `false`
`AsyncResponseAction`	Куди сценарій продовжиться після завершення фонового запиту; використовується тільки з `AsyncRequest=true`
`NextAction`	Єдиний вихід

Library default для Method — Post, але якщо поле пропустити в API DTO, C# enum default дорівнює Get. Тому метод краще завжди задавати явно.

Headers також варто передавати хоча б як порожній object {}: null може спричинити помилку під час виконання.

Connections

Вхід: один стандартний connector.
Вихід: один NextAction.
GET не надсилає body.
Для інших методів backend надсилає body як application/json.
HTTP 4xx / 5xx не зупиняє ноду винятком: isSuccess=false, після чого сценарій переходить у NextAction.
Transport, DNS або network exception зазвичай повертається як status -1, isSuccess=false і текст помилки в reasonPhrase.

Вихідні змінні

Після отримання HTTP-відповіді або обробленої transport-помилки нода створює:

#node.{id}.http.rawBody
#node.{id}.http.statusCode
#node.{id}.http.reasonPhrase
#node.{id}.http.isSuccess

В async-режимі основна гілка також отримує:

#node.{id}.http.queued

У sync-режимі http.queued відсутній або порожній.

Top-level primitive fields JSON response і response headers також стають outputs.

Наприклад, відповідь:

{
  "orderId": 501,
  "status": "created"
}

для ноди з ID 12 створить:

#node.12.orderId
#node.12.status

Якщо body field і header мають однаковий ключ, пізніше доданий header перезапише значення у спільному словнику variables.

statusCode та isSuccess зберігаються як рядки, але всередині JS автоматично перетворюються на number/boolean.

Змінні і шаблони

У Url, Headers values і BodyTemplate працюють #var та {{ JS }}.

Наприклад:

Url: https://api.example.com/cards?phone=#member.phone
Method: Post
Headers:
  Authorization: Bearer #node.3.api_token
  X-Member: #member.external_id
BodyTemplate:
  {
    "name": {{ JSON.stringify(#member.name) }},
    "amount": {{ #node.8.amount }}
  }

Async mode

Коли AsyncRequest увімкнено, нода не чекає відповіді. Запит переходить у background worker, а сценарій одразу продовжується далі. Одразу доступний тільки #node.{id}.http.queued = "True"; інші http.* outputs порожні, і наступні ноди не можуть прочитати відповідь цієї ноди.

Якщо AsyncResponseAction заданий, backend після завершення фонового запиту продовжує сценарій із цієї action у контексті того самого учасника: після success, failure або timeout. Відповідь стає доступною як звичайні #node.{id}.http.* значення та JSON-поля, а результатний екран надсилається користувачу.

Якщо AsyncResponseAction порожній, запит працює як fire-and-forget: відповідь тільки логується.

Приклад:

HTTP request (async, AsyncResponseAction -> node:31)
  -> node:31
  -> Condition "#node.12.http.isSuccess"

Test send

Редактор може надіслати test request із ноди HTTP Request без запуску сценарію. Результат показує statusCode, reasonPhrase, headers, body і прапорець isSuccess.

Якщо URL, headers або body template містять #var змінні чи {{ JS }} вирази, перед відправленням можна задати тестові значення. Редактор підказує змінні, доступні в цій ноді; значення підставляються так само, як під час runtime. Без тестових значень відсутня змінна замінюється порожнім рядком, як і в regular templates.

Важливі особливості:

Test request є реальним HTTP-запитом до налаштованого endpoint, а не sandbox. Запити, які створюють або змінюють дані у зовнішній системі, мають реальний ефект.
Test request не запускає сценарій: наступні ноди не виконуються, і #node.* вихідні змінні не створюються.

Приклад

HTTP Request
  -> Condition "#node.12.http.isSuccess"
       | true  -> JSON processor / Screen / JSON output
       | false -> fallback Screen / error JSON output

Важливі особливості

Невалідний або порожній URL може завершити execution як node failure ще до внутрішньої обробки transport exception.
Окремого ліміту розміру response body немає.
JSON arrays не розкладаються на окремі outputs. Для роботи з ними використовуйте #node.{id}.http.rawBody і parseJson(...).
Header names із дефісом можуть існувати в context, але синтаксис #var не може прочитати весь такий ключ.
Не читайте #node.{id}.http.* async-ноди в основній гілці. Використовуйте гілку AsyncResponseAction.
Не використовуйте неперевірений user input як URL: у поточному backend немає окремого SSRF allowlist.
Secrets у headers зберігаються всередині JSON схеми і повертаються у DTO ноди; це не secret vault.
HTTP Request можна використовувати в синхронному AI tool.

2. HTTP Webhook Soon

HTTP Webhook (HttpWebhook) запускає сценарій зовнішнім HTTP POST. Нода підходить для callback від CRM, платіжної системи, форми, інтегратора або іншого backend.

HTTP Webhook уже має backend API створення і runtime endpoint, але в поточному backend немає HttpWebhookNodeMapper. Через це нода не повертається у загальній DTO-відповіді схеми й поки не є повністю доступною для стандартного editor UI.

Налаштування

Поле	Значення
`Slug`	Частина URL webhook і водночас action ноди; backend зберігає trimmed slug без префікса `webhook:`
`Title`	Назва на canvas; якщо порожня, backend формує `Webhook {slug}`
`NextAction`	Єдиний вихід

Connections

HTTP Webhook є точкою входу і не має звичайного вхідного connector.
Вихід: один NextAction.
Після розбору request body нода передає виконання в NextAction.

Виклик

Backend підтримує два маршрути:

POST /webhook/{schemaId}/{slug}/{memberId}
POST /webhook/{schemaId}/{slug}

Маршрут:

POST /webhook/{schemaId}/{slug}

має [AllowAnonymous].

Маршрут із {memberId} успадковує authorization-вимогу BaseController і не є публічним webhook endpoint.

Публічний маршрут шукає учасника за top-level string-полем Phone у JSON body. Регістр назви поля не має значення. Числове, вкладене або не-JSON значення не використовується як телефон.

Якщо учасника знайдено, сценарій отримує member variables і може показати йому наступний Screen.

Вихідні змінні

JSON body записується як:

#webhook.body

Primitive fields body також розкладаються у змінні ноди.

Для body:

{
  "orderId": 105,
  "status": "paid"
}

нода з ID 7 створить:

#node.7.orderId
#node.7.status

Webhook повертає просту відповідь без налаштовуваного response body. Business result потрібно передавати в наступний Screen або зовнішню систему.

Приклад

HTTP Webhook "payment"
  -> Condition status == paid
       -> Screen / HTTP Request

Важливі особливості

Публічний webhook за телефоном не перевіряє підпис сторонньої системи. Якщо потрібна автентичність, її слід забезпечити на рівні gateway або додаткової інтеграційної логіки.
Якщо Phone відсутній, невалідний або учасника не знайдено, phone-route відповідає 200 OK без запуску корисного member-flow.
Маршрут із {memberId} запускає chain із синтетичним UserContext (UserId="webhook"), тому реальні member variables у flow не передаються.
Phone-route після успішного lookup запускає chain із реальним member context, зберігає новий screen state і підтримує Telegram/Viber-відправлення.
Зміна Slug для існуючого NodeId може залишити старий action у serialized chain, бо replace виконується за action-ключем.
Однаковий slug може замінити ноду, яка вже займає цей action.
Поточний контролер у багатьох помилкових або неповних сценаріях повертає 200 OK, щоб зовнішня система не робила нескінченні retry.
Масиви та частина nested JSON мають ті самі обмеження extractor, що й JSON processor.
HTTP Webhook є зовнішньою точкою входу, тому не рекомендується як processing step усередині синхронного AI tool.