31.12.2025
70

HTTP Request

HTTP Request

HTTP Request — це основний блок для взаємодії з будь-якими зовнішніми API. Він дозволяє виконувати запити (GET, POST, тощо), отримувати дані та використовувати їх у логіці вашого флоу.

Навігація

  1. Основні налаштування HTTP Request.
    1.1. Settings
    1.2. Як формувати URL
    1.3. Як формувати HEADERS
    1.4. Як формувати BODY
  2. Робота з відповіддю та результат виконання
  3. Приклади використання та комбінація з іншими блоками
    HTTP + IF
    Object Builder + HTTP
    HTTP + Loop: Object/List + Object Builder
    HTTP + IF + Set Validation Result
    HTTP + Add Result to Output
  4. FAQ
***

Основні налаштування (Tabs)

─────────────────────────────────────────────────────────────-

Settings

У вкладці Settings задаються ключові параметри HTTP-запиту та його поведінка під час виконання.

HTTP Request | Основні налаштування


1 -> 
URL: Endpoint зовнішнього API (можна використовувати змінні в режимі EXP).

2 -> Method: метод запиту, GET (отримання), POST (створення), PUT/PATCH (оновлення), DELETE (видалення).

3 -> Parse Body:  Оберіть JSON, щоб дані стали доступні як змінні. 

4 -> Timeouts: Встановіть час очікування (за замовчуванням 30/60 сек).  

5 -> Error Flow: Обов’язково вкажіть флоу для обробки помилок (4xx, 5xx).


Як формувати URL

─────────────────────────────────────────────────────────────-

Простий варіант (Режим TXT)

HTTP Request | Простий варіант в режимі TXT


1 ->
 Перемикач режиму поля. Якщо TXT, то все обробляється як текст, якщо EXP - як вираз (наприклад, «/» у режимі TXT - це роздільник, а в режимі EXP - ділення).

-> URL для HTTP-запиту.

-> Змінна, яку можна підставляти та використовувати для формування URL.

4 -> Query Params параметри для фільтрації даних; сортування результатів; пагінації (page, limit, offset), тощо.


Просунутий варіант (EXP режим) 

HTTP Request | Просунутий варіант в режимі EXP


1 ->
 Перемикач режиму поля: EXP означає, що вміст обробляється як вираз.

2 -> Виклик зовнішньої функції: функція, що приймає аргументи та застосовується до переданих даних (наприклад, для обробки, перетворення або форматування).

3 -> Синтаксичні оператори: можуть використовуватися різні оператори (не лише крапка) для побудови виразів, об’єднання частин, передачі значень або виконання інших операцій залежно від логіки виразу.

4 -> Змінні: динамічні значення, які можна підставляти у вирази та передавати як аргументи функціям.

5 -> Модифікатор-функція: спеціальний елемент, який застосовується до змінних або результатів виразів і дозволяє обробляти дані «на льоту», змінюючи або доповнюючи їхню поведінку без попереднього збереження значення.


Як формувати HEADERS

─────────────────────────────────────────────────────────────-

У вкладці Headers задаються HTTP-заголовки запиту. Ними можна керувати передачу типу контенту, авторизації, передачу службових необхідних параметрів.

HTTP Request | Заголовки запиту


1 ->
Перемикач увімкнення/вимкнення заголовка: визначає, чи буде цей header використаний у запиті

2 -> Індикатор активного рядка: показує, що заголовок увімкнений і буде переданий у HTTP-запиті.

3 -> Поле Name: назва HTTP-заголовка, яку буде надіслано в запиті; підтримує підстановку змінних та виразів (в режимі поля EXP) для динамічного формування значення.

4 -> Поле Value: значення заголовка; підтримує підстановку змінних та виразів (в режимі поля EXP) для динамічного формування значення.


Як формувати BODY

─────────────────────────────────────────────────────────────-

У вкладці Body налаштовується тіло запиту. Тип тіла залежить від вимог API.

Важливо: в залежності від того, який ви обираєте тип body, на вкладці HEADERS автоматично змінюється заголовок "Content-type".  

HTTP Request | Доступні типи тіла запиту


URL-Encoded Params
Це формат передачі даних у тілі HTTP-запиту у вигляді пар "ключ=значення",  закодованих за стандартом application/x-www-form-urlencoded. Зазвичай використовується для простих форм.

HTTP Request | Тип Body URL-Encoded Params


1 ->
Перемикач типу тіла: визначає який тип буде використаний при відправці запиту.

2 -> Поле Name: ключ параметра; підтримує підстановку змінних та виразів (в режимі поля EXP) для динамічного формування значення.  

3 -> Поле Value: значення параметра; підтримує підстановку змінних та виразів (в режимі поля EXP) для динамічного формування значення.  


JSON-Encoded Params
Структурований формат, де дані вводяться як пари "ключ-значення", а система автоматично перетворює їх на валідний JSON-рядок з типом application/json. Переважно використовується для невеликих, фіксованих JSON-об'єктів.

HTTP Request | Тип Body JSON-Encoded Params


1 -> 
Перемикач типу тіла: визначає який тип буде використаний при відправці запиту.

2 -> поле Name: ключ параметра; підтримує підстановку змінних та виразів (в режимі поля EXP) для динамічного формування значення.  

3 -> поле Value: значення параметра; підтримує підстановку змінних та виразів (в режимі поля EXP) для динамічного формування значення.  


Raw text data

Відправка тіла запиту як звичайного, неструктурованого тексту, наприклад: Log-файлів, текстових нотаток або інших довільних даних, що не є JSON/формами. Жоден символ не змінюється, не додається і не видаляється.

Навіть якщо вставити JSON як текст, відправиться він як текст, а не як JSON-обʼєкт і не буде оброблений, виникне помилка.

HTTP Request | Тип Body Raw text data


1 -> 
Перемикач типу тіла: визначає який тип буде використаний при відправці запиту.

2 ->  поле Raw Body: напишіть довільний текст який буде відправлений в запиті; підтримує підстановку змінних та виразів (в режимі поля EXP) для динамічного формування значення.  


Raw JSON data

Використовується для складних, вкладених JSON-структур, які незручно формувати через параметри. Дозволяє ввести "сирий" JSON. Зручно коли JSON уже сформований в Object Builder (наприклад через змінну) або приходить з іншого блоку.

Для того, щоб цей тип тіла успішно був прийнятий в запиті, додатково необхідно застосовувати для змінної навісну модифікатор-функцію Encode object as JSON

HTTP Request | Тип Body Raw JSON data


1 -> 
Перемикач типу тіла: визначає який тип буде використаний при відправці запиту.

2 ->  поле Raw Body: значення яке буде надіслано в запиті; підтримує підстановку змінних та виразів (в режимі поля EXP) для динамічного формування значення.  

3 -> Модифікатор-функція: спеціальний елемент, який застосовується до змінних або результатів виразів і дозволяє обробляти дані «на льоту», змінюючи або доповнюючи їхню поведінку без попереднього збереження значення.


File by ID

Використовується для передачі файлів (зображень, документів, тощо), отриманих у попередніх блоках флоу (ідентифікується за ID).


Multipart / Related

Відправка файлів у поєднанні з додатковими полями форми (наприклад, завантажити фото і вказати його опис).


Робота з відповіддю та результат виконання

─────────────────────────────────────────────────────────────-

Response 

Відображає результат виконання HTTP-запиту без переходу до Execution Log. Він дозволяє швидко перевірити, чи коректно сформований запит і яку відповідь повертає API, ще на етапі налаштування блоку.

HTTP Request | Відповідь в Settings


Після виконання запиту у Settings в Response можна побачити:

1 -> HTTP-статус відповіді (наприклад, 200, 400, 401, 500)

2 -> тіло відповіді API (response body)

3 -> перемикачі формату відображення (дані відображаються у «сирому» вигляді або у форматі, визначеному параметром Parse Body.)


Execution Log — Результат Виконання

Вкладка Execution Log  є ключовим інструментом для тестування та відладки. Вона відображає результати фактичного виконання HTTP-запиту.

HTTP Request | Execution Log
HTTP Request | Execution Log


1 -> 
REQUEST: Фактичний запит, який був надісланий на зовнішній API, включаючи URL, метод, заголовки та тіло запиту(body).

2 -> RESPONSE: Відповідь, отримана від зовнішнього API серверу, включаючи HTTP-статус (наприклад, 200, 402) та сире тіло відповіді.  

3 -> EXECUTION RESULTSРозпарсений результат відповіді (якщо Parse Body = JSON) готовий для використання в наступних кроках Flow. Саме ці дані використовуються далі у подальшій логіці як змінні.

4 -> ERRORS: Для відображення помилок, якщо HTTP Request завершується помилкою (4xx, 5xx або некоректна відповідь)

Для глибшого вивчення просунутих можливостей блоку, архітектури його зв’язків з іншими флоу та складних сценаріїв використання перейдіть до 
Повної версії документації HTTP Request. 


Приклади використання та комбінація з іншими блоками

─────────────────────────────────────────────────────────────-

  • HTTP + IF (Умовна логіка)

Використовується для створення розгалуженої логіки на основі результатів запиту. Наприклад, ви перевіряєте успішність створення сутності (наявність ID), щоб вирішити, чи потрібно виконувати наступні кроки або додавати теги. Це дозволяє будувати безпечні сценарії, де кожен наступний крок залежить від успіху попереднього.

HTTP Request | Приклад HTTP + IF
HTTP Request | Приклад HTTP + IF
HTTP Request | Приклад HTTP + IF
HTTP Request | Приклад HTTP + IF
***

Дозволяє формувати складні вкладені структури JSON, яких вимагає специфікація API (наприклад, масиви для AI-моделей). Ви можете «збирати» об'єкт частинами, перевіряти заповненість полів і приводити дані до потрібного формату безпосередньо перед відправкою. Це забезпечує ідеальну структуру тіла запиту (Body).

HTTP Request | Приклад HTTP + Object Builder
HTTP Request | Приклад HTTP + Object Builder
HTTP Request | Приклад HTTP + Object Builder
***

Застосовується для трансформації списків, отриманих від API. Ви проходите циклом по масиву (наприклад, списку доступних моделей або категорій) і за допомогою Object Builder перетворюєте їх у динамічний список. Це дозволяє виводити актуальні дані з API прямо в інтерфейс користувача (наприклад, у випадаючі списки).

HTTP Request | Приклад HTTP + Loop: Object/List + Object Builder 
HTTP Request | Приклад HTTP + Loop: Object/List + Object Builder 
HTTP Request | Приклад HTTP + Loop: Object/List + Object Builder 
HTTP Request | Приклад HTTP + Loop: Object/List + Object Builder 
***

Класична зв'язка для флоу Account Validation. Ви виконуєте тестовий запит до API, а блок IF перевіряє наявність ключових полів або статус-код у відповіді. На основі цієї перевірки блок Set Validation Result фіксує статус: «1» (валідний акаунт) або «0» (помилка авторизації).  

HTTP Request | Приклад HTTP + IF + Set Validation Result
HTTP Request | Приклад HTTP + IF + Set Validation Result
HTTP Request | Приклад HTTP + IF + Set Validation Result
***

Використовується для миттєвої передачі даних з відповіді API у фінальний результат інтеграції. Це дозволяє «прокинути» отриману інформацію у флоу Output, щоб користувач міг побачити результати роботи сценарію та використовувати ці дані для мапінгу в інших системах.

HTTP Request | Приклад HTTP + Add Result to Output
HTTP Request | Приклад HTTP + Add Result to Output


FAQ

─────────────────────────────────────────────────────────────-

1. Де подивитися результат виконання HTTP-запиту?
Результат доступний у вкладці Execution Log, у секції Response (вкладка Settings) або в загальному Лозі. Там відображаються фактичний запит (URL, заголовки, тіло), статус-код відповіді, сирий response та розпарсені дані (Execution Results).

2. Чому HTTP Request не виконується або повертає порожню відповідь?

Основними причинами є неправильний HTTP-метод, некоректний URL, відсутність обов’язкових заголовків (наприклад, Authorization), помилки в структурі Body або особливості самого API. Рекомендуємо завжди перевіряти Execution Log для аналізу помилок.

3. Як передати дані з HTTP Request в інші блоки?

Після запиту всі розпарсені дані з Execution Results стають доступними як змінні. Їх можна використовувати в блоках IF, Object Builder, Loop, Add Output та інших через стандартну структуру вибору змінних у флоу.

4. Чи можна використовувати змінні та функції в HTTP Request?

Так, блок підтримує використання змінних із попередніх кроків, функцій та операторів у режимі EXP, а також динамічну підстановку значень безпосередньо в URL, заголовки та тіло запиту.

5. Що робити, якщо API працює нестабільно?

Для стабільної роботи використовуйте Error Flow для обробки збоїв, збільшуйте Timeout у налаштуваннях, обов'язково перевіряйте наявність даних у відповіді перед їх використанням та тестуйте сценарій з різними станами відповідей API.