cURL Import and design time testing This section helps you configure the activity via the cURL code snippets, and perform design time testing of the request. |
- cURL Command Text—Multiline design-time text field where a full cURL command can be pasted. Supports both `cm and bash styles.
- cURL import button—Action button that immediately triggers parsing/import of the current cURL Command Text into the activity (method, URL, headers, body, auth, files).
- Test request button—Action button that executes the configured request at design time. While running, it toggles to Cancel. On completion or cancellation
it reverts to Test and updates Report field with formatted response or error.
- Report—Multiline text area used to display the outcome of the last cURL import or design-time test execution (success summary, mapping
details, warnings, or errors).
|
This section helps you define connection-related settings. |
|
This section helps you define how the activity authenticates itself with the server. | Authentication—Select the authentication method. Available options are:
- No authentication—The server does not require user validation to accept your request.
-
Basic authentication—Provides user validation to the receiving sever through Username and Secure Password.
Switch between plain and secure passwords by selecting the plus icon and choosing the desired option: Use plain string and Use secure string.
- Bearer token—Provides user validation to the receiving server through a unique Bearer token generated after login.
- Negotiated authentication—Use the HTTP Negotiate scheme for the runtime to select Kerberos or NTLM (and optionally Digest) based on server challenges.
When Authentication is set to Negotiated authentication and Use operating system credentials = True, the current OS user context is used (Windows logon token; on Linux/macOS an existing Kerberos ticket, e.g. from kinit).
Set Use operating system credentials = False to enable the Custom credentials field; supply a NetworkCredential (domain / username / password or secure password).
|
This section helps you define the behavior of the request. |
- Additional cookies—Manually specify extra cookies as key-value pairs.
- Request timeout—Specify the maximum wait time, in milliseconds, before the request aborts. Default value is 10,000 milliseconds (10 seconds).
- Continue on error—Decide if the automation should continue even when the activity throws an error (True, default option). To stop the automation when an error occurs, use False.
- Follow redirects—Decide if your request should automatically follow URL redirects provided by the server (True, default option). To ignore redirects and use the initial response, use False.
- Maximum redirects—Specify how many automatic redirects you request should follow before stopping. Default value is 3.
|
This section helps you define the retrying mechanism in case of request failure. | Retry policy type—Specify the method for retrying requests. Available options are:
- No retry—Your request calls the server only once. If it fails, no further attempts occur.
- Basic retry—Retries the request after failures using a fixed delay.
- Retry count—Specify the number of times to retry. Default value is 3.
- Delay—Specify the fixed time between retries in milliseconds. Default value is 500 milliseconds (0.5 seconds).
- Use Retry-After header—Decide if the request should use the Retry-After header recommended by the server (True, default option). To ignore the Retry-After header value, use False.
- Delay limit—Specify the maximum allowed delay between Retry-After retries, in milliseconds. Default value is 30,000 milliseconds (30 seconds).
- Retry status codes—Specify the status codes that should trigger retries.
- Exponential backoff—Retries with increasing delays between each attempt.
- Retry count—Specify the number of times to retry. Default value is 3.
- Inital delay—Specify the delay time before the first retry, in milliseconds. Default value is 500 milliseconds (0.5 seconds).
- Multiplier—Specify the number used to increase the delay after each failed request. Default value is 2, which doubles the delay each
time.
- Use jitter—For delays, decide if you want to add a random offset between 0 and 100 milliseconds to avoid synchronized retries (True, default).
- Use Retry-After header—Decide if the request should use the Retry-After header recommended by the server (True, default option). To ignore the Retry-After header value, use False.
- Delay limit—Specify the maximum allowed delay between Retry-After retries, in milliseconds. Default value is 30,000 milliseconds (30 seconds).
- Retry status codes—Specify the status codes that should trigger retries.
|
This section helps you customize how the response will be returned by the server. |
- Always save tesponse as file—Force writing the response body to disk even when an attachment filename is not inferred.
- Enable debugging info—Enable extended debug capture (raw request/response metadata, headers snapshot, timing, retry details) and output to the
response object or during design time testing.
- Output file name—Override the server-provided filename (e.g. from Content-Disposition).
- Output file target folder—Control destination folder for the saved response files.
- If the file already exists—Define collision strategy when a file with the resolved name already exists in the target folder.
Options:
- Auto rename—Append incremental suffix (_1, _2, …) to produce a unique filename.
- Replace—Overwrite existing file.
- Stop and discard—
- Abort the save operation (and workflow if the exception is not handled) leaving existing file intact.
|
This section helps you capture and store the response returned by the server. | Response content—Captures the response from the server and stores it to a variable, for future processing. It includes:
- StatusCode—HTTP response status code.
- TextContent—Response as plain text (if available).
- BinaryContent—Raw response data for non-text content.
- File—Response saved as a file (ILocalResource) in your Downloads folder. The filename is from response headers or auto-generated to avoid overwriting files.
- Headers—All HTTP response headers.
- ContentHeaders—Headers specifically related to the response content. For example, Content-Type and Content-Length.
- RawRequestDebuggingInfo—Optional string containing captured low-level request/response details (e.g. constructed request line, headers, retries, timing)
populated only when debugging is enabled; empty string otherwise.
|
