HTTP Request


Figure 1: HTTP Request Node


By using the HTTP Request Node you are able to perform a HTTP request to a specific resource from within a Flow.

Whenever the HTTP Request Node gets triggered within a Flow execution it will perform the defined request to the specified URL.


Figure 2: HTTP Request Node Configuration Prompt

1 Request Methods

Right now you can execute the typical CRUD methods, which are:

  • GET
  • POST
  • PUT

You can set the type of the request by expanding the type dropdown within the node configuration (see Figure 3).


Figure 3: Type Selection Dropdown

2 General Configuration

Each request method has some field which it shares with the other methods. These are the fields:

  • URL
  • Headers
  • Authorization Type
  • Context Store
  • Async
  • Caching
    • Cache Expiry

2.1 URL

The URL to the targeted resource.


Figure 4: URL field



Cognigy.AI expects the not encoded URL to the targeted resource. Please decode any encoded URL to ensure, that the HTTP Request can be successful.

For more information see URL encoding (on en:WP).

2.2 Headers

Here you can add the headers you need to successfully perform the HTTP request.


Figure 5: Headers fields

2.3 Authorization Type

The supported types are:

  • No Auth
  • Basic Auth
  • OAuth2
  • API Key - "Authorization: ApiKey"
  • API Key - "X-API-Key"

Figure 6: Authorization Selection

In case you select a authorization type other than No Auth you'll get additional fields which depend on the selected authorization type.

2.4 Context Store

Here you define the context key where you want to store the response from the executed HTTP request. The field is required and needs to have a valid value.


Figure 7: Context Store field

After the HTTP request has been successfully executed you can access the response payload by executing the following CognigyScript:


2.5 Async

This toggle changes whether the HTTP request gets executed asynchronously or not. In case it is toggled on the HTTP request won't pause the flow execution while performing the request and waiting for the reponse.

2.6 Caching

Here you can set whether the request gets cached or not. You can also set a period of time in seconds for the expiration of the cached request.

3 GET Configuration

The GET method configuration prompt has all the fields which are described in section 2.

The results of the GET request are stored in the context of the flow. You can get the requested data of your GET request by accessing the context with the key you defined in the HTTP request (see section 2.4).

4 POST Configuration


Content-Type Headers

The standard Content-Type header is application/x-www-form-urlencoded. If you want to send another Content-Type, you have to set the header value specifically or use JSON as described below.

The POST request configuration prompt has - beside the General Configuration fields (see section 2) - an additional toggle Payload is JSON and a input field Payload

Payload is JSON

If the toggle is set to true you'll get an adjusted Payload input field for entering the JSON data. The toggle also enables the Content-Type: application/json header for the POST request.


Here you can define the payload of your POST request.


Figure 8: JSON as POST Request Payload



You can send URL Encoded data by setting no specific header and then sending a URLEncoded non-JSON payload like for example "To=%2B49555262626&"

5 PUT Configuration

The PUT request configuration prompt exposes - beside the General Configuration fields (see section 2) - the same configuration fields as the POST request configuration prompt does. So have a look at section 4 for a detailed description.

6 DELETE Configuration

The DELETE request configuration prompt exposes the General Configuration fields (see section 2).