Cognigy.AI Docs

COGNIGY.AI is the Conversational AI Platform focused on the needs of large enterprises to develop, deploy and run Conversational AI’s on any conversational channel.

Given the arising need of voice interfaces as the most natural way of communicating with brands, Cognigy was founded in 2016 by Sascha Poggemann and Phil Heltewig. Our mission: to enable all devices and applications to intelligently communicate with their users via naturally spoken or written dialogue.

Get Started

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

Request Methods

The HTTP Node can execute the typical CRUD methods, which are:

  • GET
  • POST
  • PUT

General Configuration

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

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


The URL to the targeted resource.

Figure 4: URL field



Cognigy.AI expects an un-encoded URL to the targeted resource. Please decode any encoded URL to ensure that the HTTP Request can be executed successfully.

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


Here you can add the headers you need to successfully perform the HTTP request, in JSON format.

You can also optionally store the response headers.

Figure 5: Headers fields


The supported types are:

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

Authentication makes use of Connections, which means that the actual authentication information can be encrypted.

Figure 6: Authorization Selection

When a new authentication connection is created by clicking the "+" button next to the Parameters field, the "New Connection" window will appear to request the details specific to the authentication type.

As an example: The OAuth2 Connection is displayed below, allowing customized parameters to be configured.

Figure 7: Example Connection: OAuth2

In case you select an authorization type other than No Auth, additional fields will be provided which relate to the respective authorization type.

Storage Options

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

Figure 8: Context Store field

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


Figure 9: Execution and Caching

Execution & Caching

Execute Requests asynchronously

When enabled, the HTTP Request Node will execute the request asynchronously, meaning that it will not wait for a response before continuing flow execution

Cache Results

When enabled the HTTP Node will cache the responses.

Figure 10: Security


Allow Insecure SSL

By default Cognigy.AI will reject connecting against insecure SSL endpoints, such as URLs with no or self-signed certificates. Activating this option will allow the Node to connect against these URLs as well.

Figure 11: Error Handling

Error Handling

Error Logging

If HTTP Requests return a status code > 299, the response is considered an error. This setting allows the user to either:

  • not log the error
  • log the error with the response from the server and the URL
  • log the error, the reponse, the URL and the request payload (WARNING: This could expose sensitive data in the logs)
Abot Flow Execution on Error

If active, the Flow will stop here if the response returned with a status code > 299

GET Requests

The GET method configuration prompt has all the fields described above.

The results of the GET request are stored in the context of the flow. You can retrieve the requested data of your GET request by accessing the context with the key you defined in the HTTP Node settings.

POST Requests


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.


Here you can define the payload of your POST request. You can choose between JSON (standard) and Text.

Figure 12: JSON as a POST Request Payload



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

PUT Requests

Aside from the General Configuration fields (see above), the PUT request configuration prompt exposes the same configuration fields as the POST request configuration prompt.

DELETE Requests

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

Updated 8 days ago

What's Next


HTTP Request

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.