HTTP Task

"type" : "HTTP"

The HTTP task (HTTP) is useful for make calls to remote services exposed over HTTP/HTTPS. It supports various HTTP methods, headers, body content, and other configurations needed for interacting with APIs or remote services.

The data returned in the HTTP call can be referenced in subsequent tasks as inputs, enabling you to chain multiple tasks or HTTP calls to create complex flows without writing any additional code.

You can reuse an HTTP service registered in Remote Services to populate the HTTP task's endpoint details. Global service settings and circuit breaker settings apply to HTTP tasks.

Task parameters

The HTTP request parameters can be specified directly in inputParameters or nested inside inputParameters.http_request. Both forms are supported — the flat form is simpler for most use cases.

Parameter	Type	Description	Required / Optional
uri	String	The URI for the HTTP service. Supports dynamic references like ${workflow.input.url}.	Required.
method	String	The HTTP method. Supported methods: GET, PUT, POST, PATCH, DELETE, OPTIONS, HEAD, TRACE.	Required.
accept	String	The accept header required by the server. Default: application/json.	Optional.
contentType	String	The content type for the request. Default: application/json.	Optional.
headers	Map[String, Any]	A map of additional HTTP headers to be sent along with the request. See Sending headers below.	Optional.
body	Map[String, Any]	The request body.	Required for POST, PUT, or PATCH methods.
asyncComplete	Boolean	Whether the task is completed asynchronously. Default: false. When true, the task stays IN_PROGRESS until an external event marks it as complete.	Optional.
connectionTimeOut	Integer	The connection timeout in milliseconds. Default: 100. Set to 0 for no timeout.	Optional.
readTimeOut	Integer	Read timeout in milliseconds. Default: 150. Set to 0 for no timeout.	Optional.
hedgingConfig.maxAttempts	Integer	The maximum number of parallel requests to send. The first successful response is used, which helps reduce tail latency in remote services. Hedging makes parallel requests, so use it only for idempotent services.	Optional.
encode	Boolean	Whether Conductor encodes the query parameters of the URI before sending the request. Set to false if the URI is already encoded. The default value is true.	Optional.
acceptedStatusCodes Available since: v5.2.97 and later	List[String]	A list of HTTP status codes or families to treat as successful. Supports exact codes such as "404" and family wildcards such as "4xx". If not set, only 2xx responses are treated as successful. If set, only the listed codes are accepted, so add "2xx" explicitly to accept it as well.	Optional.

Configuration JSON

Here is the task configuration for an HTTP task. Note that parameters are specified directly in inputParameters:

{
  "name": "http",
  "taskReferenceName": "http_ref",
  "type": "HTTP",
  "inputParameters": {
    "uri": "https://api.example.com/data",
    "method": "POST",
    "headers": {
      "Authorization": "Bearer ${workflow.input.api_token}",
      "X-Request-Id": "${workflow.correlationId}"
    },
    "body": {
      "key": "value"
    }
  }
}

Legacy http_request form

The nested inputParameters.http_request form is still supported for backward compatibility:

"inputParameters": {
  "http_request": {
    "uri": "https://api.example.com/data",
    "method": "POST",
    "body": { "key": "value" }
  }
}

Both forms work identically. The flat form (shown above) is recommended for new workflows.

Sending headers

Use the headers parameter to send custom HTTP headers, including authentication:

Bearer token authentication

{
  "name": "call_api",
  "taskReferenceName": "call_api_ref",
  "type": "HTTP",
  "inputParameters": {
    "uri": "https://api.example.com/protected/resource",
    "method": "GET",
    "headers": {
      "Authorization": "Bearer ${workflow.input.access_token}"
    }
  }
}

API key authentication

{
  "name": "call_api",
  "taskReferenceName": "call_api_ref",
  "type": "HTTP",
  "inputParameters": {
    "uri": "https://api.example.com/data",
    "method": "GET",
    "headers": {
      "X-API-Key": "${workflow.input.api_key}"
    }
  }
}

Basic authentication

{
  "name": "call_api",
  "taskReferenceName": "call_api_ref",
  "type": "HTTP",
  "inputParameters": {
    "uri": "https://api.example.com/data",
    "method": "GET",
    "headers": {
      "Authorization": "Basic ${workflow.input.basic_auth_token}"
    }
  }
}

Multiple custom headers

{
  "name": "call_api",
  "taskReferenceName": "call_api_ref",
  "type": "HTTP",
  "inputParameters": {
    "uri": "https://api.example.com/data",
    "method": "POST",
    "headers": {
      "Authorization": "Bearer ${workflow.input.token}",
      "X-Correlation-Id": "${workflow.correlationId}",
      "X-Request-Source": "conductor",
      "Accept-Language": "en-US"
    },
    "body": {
      "data": "${workflow.input.payload}"
    }
  }
}

Output

The HTTP task will return the following parameters.

Name	Type	Description
response	Map[String, Any]	The JSON body containing the request response, if available.
response.headers	Map[String, Any]	The response headers.
response.statusCode	Integer	The HTTP status code indicating the request outcome.
response.reasonPhrase	String	The reason phrase associated with the HTTP status code.
response.body	Map[String, Any]	The response body containing the data returned by the endpoint.

Execution

The HTTP task is moved to COMPLETED status once the remote service responds successfully.

If your HTTP tasks are not getting picked up, you might have too many HTTP tasks in the task queue. Consider using Isolation Groups to prioritize certain HTTP tasks over others.

Examples

Here are some examples for using the HTTP task.

GET Method

{
  "name": "Get Example",
  "taskReferenceName": "get_example",
  "type": "HTTP",
  "inputParameters": {
    "uri": "https://jsonplaceholder.typicode.com/posts/${workflow.input.queryid}",
    "method": "GET"
  }
}

POST Method

{
  "name": "http_post_example",
  "taskReferenceName": "post_example",
  "type": "HTTP",
  "inputParameters": {
    "uri": "https://jsonplaceholder.typicode.com/posts/",
    "method": "POST",
    "body": {
      "title": "${get_example.output.response.body.title}",
      "userId": "${get_example.output.response.body.userId}",
      "action": "doSomething"
    }
  }
}

PUT Method

{
  "name": "http_put_example",
  "taskReferenceName": "put_example",
  "type": "HTTP",
  "inputParameters": {
    "uri": "https://jsonplaceholder.typicode.com/posts/1",
    "method": "PUT",
    "body": {
      "title": "${get_example.output.response.body.title}",
      "userId": "${get_example.output.response.body.userId}",
      "action": "doSomethingDifferent"
    }
  }
}

DELETE Method

{
  "name": "DELETE Example",
  "taskReferenceName": "delete_example",
  "type": "HTTP",
  "inputParameters": {
    "uri": "https://jsonplaceholder.typicode.com/posts/1",
    "method": "DELETE"
  }
}

Accepting non-2xx status codes

Use acceptedStatusCodes when your workflow should continue even if the HTTP response is not a 2xx status code.

{
  "name": "http",
  "taskReferenceName": "http_ref",
  "type": "HTTP",
  "inputParameters": {
    "uri": "https://example.com/api/resource/123",
    "method": "GET",
    "accept": "application/json",
    "contentType": "application/json",
    "acceptedStatusCodes": ["2xx", "404"]
  }
}

When acceptedStatusCodes is set, "2xx" is not automatically included. Add it explicitly if you want both 2xx and other codes to be accepted.

Related pages

• System Tasks
• Publish events with the Event task
• HTTP Poll
• Inline Task
• JSON JQ Transform Task
• Business Rule