HTTP Request
Description
The HTTP Request action allows a flow to perform HTTP actions on REST endpoints.
Additional information can be passed as header information such as Content-Type and MIME types, and as content containing the request body information.
After the request is executed an HTTP response status code is returned with the response content as a string.
Usage
The HTTP Request action allows your application to integrate with external applications and services to, for example:
- Extend the functionality of your application by leveraging external data, services, and resources.
- Submit, update and retrieve data.
- Orchestrate services and manage inter-service communication.
- Trigger actions in other applications and systems, such as start a process, send automated notifications, or automate backups.
Basic configuration
Basic configuration involves defining:
-
The authentication mechanism, if any, to be used when connecting with the remote server. You can configure the following types of authentication:
- None: No authentication needed.
-
Basic: Basic authentication is a simple authentication scheme built into the HTTP protocol. The client sends HTTP requests with the Authorization header, that contains base64-encoded username and password.
-
Bearer: Bearer authentication, also called token authentication, is an HTTP authentication scheme that involves security tokens called bearer tokens. The name Bearer authentication can be understood as give access to the bearer of this token.
-
The method to be used in the request. The following methods are currently supported:
- GET
- HEAD
- POST
- PUT
- DELETE
- OPTIONS
- PATCH
-
The URL of the remote server.
Advanced configuration
Advanced configuration allows you to attach certificates and disable retry requests for the HTTP request.
Certificates
You can attach a Client Certificate in the Advanced configuration section, where a drop-down allows you to select one of the certificates added for this tenant.
The option to attach a Remote Certificate is also available to provide added identity authentication on received data through a mTLS protocol. For more details about setting up certificates, see Certificates.
Note: You must provide a Client Certificate before you can add a Remote Certificate to the HTTP request.
Disable Retry Requests
The Disable Retry Requests setting allows you to deactivate retry requests with only retries being sent for the error response 429 Too Many Requests.
In some cases, when the external endpoint does not respond within the default timeout for the HTTP Request action of 100 seconds, a retry mechanism resends the request. In some situations this retry can result in the request being posted twice because the external endpoint is still handling the first request. The Disable Retry Requests setting is available to handle such situations.
General retry settings
The HTTP request uses default retry settings to ensure resilience and handle common transient errors effectively.
- 408 - Request Timeout
- 429 - Too Many Requests
- 5XX - Server Error Responses
The maximum number of retries set for each operation is 5.
The complete retry operation (within the retries and corresponding waiting times in between) will timeout after 9 minutes.
Each retry operation will timeout after 100 seconds.
| Retry setting | Description |
|---|---|
| Retry- After | The Retry-After header is a standard response HTTP header that indicates how long the user agent should wait before making another request. It is sent within statuses 503 (Service Unavailable), 429 (Too Many Requests) as detailed Retry-After. It is taken into account in the default retry pattern implementation. |
| 429 - Too Many Requests | When a status 429 - Too Many Requests response is returned by the HTTP request, the waiting time before retrying is: - Retry-After header value if received with a maximum time of thirty seconds - A random amount of time as per this distribution. The random time is generated between 250 milliseconds and 30 seconds. |
| 503 - Service Unavailable | When a status 503 (Service Unavailable) is returned by the HTTP request, the waiting time before retrying is: - Retry-After header value if received (with a maximum time of one minute) - One minute wait if no Retry-After header is received |
| Any of the other status considered previously as transient | When a status 5XX (Server error) besides 503, or 408 (Request timeout) is returned by the HTTP request, the waiting time before retrying is: - A random amount of time as described in Exponential Backoff And Jitter distribution. The random time is generated between 250 milliseconds and 30 seconds. |
Content definition
The Content definition section is where you define the following:
- Content type
- Content of the request body
- Header information
Content type
The Content Type drop-down list presents the most common content types, but if the content type you wish to use is not listed here, you can manually enter it.
The listed content types are:
| Content type | Description |
|---|---|
| JSON (application/json) | JSON formatted data using JSON's standard UTF-8 encoding. Note: If you do not want the content type to include the encoding information, then you must add a space after the application/json entry.  |
| JSON Patch (application/json-patch+json) | Used to define a JSON document format for expressing a sequence of operations to be applied to a JSON document. |
| XML (application/xml) | XML formatted data. |
| XML (text/xml) | XML formatted data. |
| Text (text/plain) | Plain text with no specific formatting. |
| x-www-form-urlencoded | The default content type for HTML forms. Form data is encoded as key-value pairs, similar to query parameters in the URL. |
| Multipart/form-data | Used for uploading files through HTML forms. |
| Binary (application/octet-stream) | A generic stream of binary data used for file uploads when the file type is unknown or not specified. |
| XML (application/soap+xml) | Used to signify that the body of the message contains a SOAP envelope formatted as XML. |
Multipart/form-data content type support
The HTTP Request action supports the use of the Multipart/form-data content type to allow data to be uploaded using HTML forms.
Once you have selected the content type, a new Form Data section is displayed, where you configure the form data.
You can add and configure form data fields by selecting the Add button and adding the information in the pop-up window.
The following field types are available:
- Text: The Text form data value requires a key and value provided in the configuration.
- File: The File form data value requires a key, the file content value and a filename. The supported file content is plain text for text files (XML, CSV, JSON, etc.) and base64 encoding for binary files (PDF, PNG, etc.).
Content
The Content section is where you define the body content of the HTTP request. This data can be of various types, such as JSON, XML, plain text, form data, or file uploads, depending on the content type.
Headers
The Headers section is where you define any HTTP request header information in addition to the Content Type already defined. Header information is defined as key-value pairs, for example:
Input samples in JSON notation
Authentication type: None
{
'AuthenticationType': 'None'
'Method': 'string',
'Url': 'string',
'ContentType': 'string',
'Content': 'string',
'Headers': {
'key': 'value'
}
}
Authentication type: Basic
{
'AuthenticationType': 'Basic',
'Username': 'string',
'Password': 'string',
'Method': 'string',
'Url': 'string',
'ContentType': 'string',
'Content': 'string',
'Headers': {
'key': 'value'
}
}
Authentication type: Bearer
{
'AuthenticationType': 'Bearer',
'Token endpoint': 'string',
'Client': 'string',
'Client Secret': 'string',
'Requested Scope': 'string',
'Method': 'string',
'Url': 'string',
'ContentType': 'string',
'Content': 'string',
'Headers': {
'key': 'value'
}
}
Output sample
{
'StatusCode': 200,
'Headers': {
'key': [
'value'
]
},
'Response': 'string'
}