HTTP task

Use an HTTP task when a workflow must send a request to another web service, also called an API. An endpoint is the URL of the specific API operation or service you want to call.

Configure Credentials when authentication is needed, then set the URL, HTTP method, headers, and body mode: no body, text or expression, or JSON. Set connection and read timeouts for the target. Input Parameters can build request values and Retry can handle temporary service failures. When it runs, SimWorkflow sends the request and makes the response available to later tasks.

Test request

Click Test request to run the currently configured HTTP form with its current task input. Inspect the result to find credential, request, or configuration errors early. Testing does not save, publish, or start the workflow.

For an external API, use a public HTTP or HTTPS URL; local and private addresses are not supported. External Test requests support GET and POST, use selected credentials rather than your browser login, and do not follow redirects automatically. Running HTTP tasks retain their configured methods and credentials.

The preview shows JSON responses as structured data. YAML, CSV and XML responses stay as their original text, without automatic file conversion. This preview is separate from executing the workflow: the HTTP task's normal response-handling rules below still apply when it runs. Use a JSON Converter task when you explicitly want to convert a source file into a JSON file.

Field	Required	Default Value	Description
`Credentials`	No	N/A	Selects the authentication record used by the request. Choose it only when the target API requires authentication.
`URL`	Yes	N/A	Sets the endpoint called when the task runs. It can use expression-capable values from the task input where appropriate.
`Method`	Yes	`GET`	Selects the HTTP method sent to the endpoint. Match the API operation you intend to call.
`Headers`	No	`Accept: application/json`; `Content-Type: application/json`	Provides the repeatable request-header list. The new HTTP task starts with these two JSON-oriented headers; add, remove, or edit entries to match the target API.
`Headers` key	No	N/A	Sets one request-header name. Add a separate header row for each header required by the target API.
`Headers` value	No	N/A	Sets the value paired with its header name. It is sent with the request and can use expressions where appropriate.
`Body mode`	No	No body	Selects whether the request has no body, a text/expression body, or a JSON body. It determines which body control is shown.
`Body`	When a text/expression or JSON body mode is selected	N/A	Supplies the request content. JSON mode requires valid JSON; text/expression mode sends the entered content.
`Connection time out in seconds`	No	`5` for a new HTTP task	Limits how long SimWorkflow waits to establish a connection to the target service.
`Read time out in seconds`	No	`10` for a new HTTP task	Limits how long SimWorkflow waits for the target service to return its response after connecting.

Example: look up a customer in another service

Suppose your test service looks up a customer by its number. Give an HTTP task the name Fetch customer and set Input Parameters to:

{
  "customerId": "${workflow.input.customerId}"
}

Choose GET, no body, and the service's real approved URL, such as https://example.com/customer/${customerId}. This example address is illustrative; replace it with your service's test address and appropriate credentials.

For input customerId: 104, suppose that service returns JSON {"id":104,"name":"Example"} with HTTP 200. The task output includes these fields, alongside response headers and content information:

{
  "statusCode": 200,
  "body": {
    "id": 104,
    "name": "Example"
  },
  "swf:file": null
}

This is an output excerpt, not the complete response envelope. Map {"customerName":"${['Fetch customer'].output.body.name}"} into a later task. If body is not inline and swf:file is present, use the supported attachment path instead; do not assume .body.name exists. Check the status and response before retrying. Test request can really call the service, and POST or other write operations may change remote data. Use a safe test destination. Entered timeouts must be at least one second; increasing a timeout does not correct a wrong URL, unavailable credential, or rejected request.

Example

Enter a nonblank URL and select the method your service accepts: GET, HEAD, POST, PUT, PATCH, DELETE or OPTIONS. Add headers as name/value rows. URL, header values and body can select mapped task-input values. For a request body, choose text/expression or JSON and enter the required content. A complete authorized swf:file:<id> body reference sends that file's bytes. Entered timeouts must be whole numbers of at least one second; leave them blank to use the service default.

Configure the example using its visible controls:

Select HTTP Task, name it Fetch customer, and map customerId on Input Parameters as above. Open Configuration, keep GET, enter https://example.com/customer/${customerId} in URL, and leave Body at No body. Select credentials only if your real endpoint needs authentication. This illustrative endpoint and response are not a live API promise.

Input

Captured task data after Input Parameters mapping:

{
  "customerId": 104
}

Output

headers is an object whose values are arrays of strings; statusCode and reasonPhrase identify the response; contentLength is bytes, contentType the media type. body contains supported parsed JSON/YAML/CSV/XML or text/HTML when it fits. swf:file is null inline; otherwise it describes the complete file and body is null. A valid JSON null and an empty response both can have null body/file; check status, type and length. Unknown/binary content or invalid JSON can be a file.

Raw task output:

{
  "headers": {
    "Content-Type": [
      "application/json"
    ]
  },
  "statusCode": 200,
  "reasonPhrase": "OK",
  "contentLength": 27,
  "contentType": "application/json",
  "body": {
    "id": 104,
    "name": "Example"
  },
  "swf:file": null
}

When something goes wrong: A received non-2xx status fails the task and can retain the HTTP response output. Network/timeout/size failures can have missing response details; inspect task status and reason before consuming output. Check credentials, URL, method, headers, body, timeouts and endpoint availability, or reduce the requested response. Only configured retryable failures retry; a response file still has file/storage limits.

A following task can map this value: ${['Fetch customer'].output.body.name}.