Skip to main content


"type" : "HTTP_POLL"


The HTTP_POLL is a conductor task used to invoke HTTP API until the specified condition matches.

Use Cases

The HTTP_POLL task comes into use in situations like State Monitoring, where you need to monitor a particular state. For example, you can leverage this to monitor issues in GitHub so that you get notified of the issues at every specified time.


You can define the http_poll tasks in the workflow with the task type HTTP_POLL.

To proceed with the workflow creation, you must specify the input parameters.

Input Parameters

The input parameters supported by the HTTP_POLL task are as follows:

terminalConditionSpecifies the condition to be evaluated after every HTTP API invocation. If the condition is evaluated as true, the task will be marked as completed. On the other hand, if the condition is evaluated as false, the conductor will schedule the next poll according to the configurations (pollingInterval & pollingStrategy). Note: While writing the terminal condition,
  • It can be parameterized.
  • In order to use the current http poll as input to the condition, a $ needs to be prefixed. For example, $.output.status
pollingIntervalSpecify the time duration in seconds between each HTTP invocation.
pollingStrategyIt can take any of the following values:
  • FIXED - The duration between each HTTP API invocation will be fixed.
  • LINEAR_BACKOFF - The duration between each HTTP API invocation will be calculated by multiplying the poll count with pollingInterval. Note that the poll count is the incremental value based on each invocation.
  • EXPONENTIAL_BACKOFF - The duration between each HTTP API invocation will be calculated by multiplying poll count with 2 base exponential of pollingInterval.

Apart from the above parameters, ensure that the following basic parameters for an HTTP task are also provided.

uriProvide the Uniform Resource Identifier (URI) for the service. It can be partial when using vipAddress or else it indicates the server address.
methodIndicates the required action to be performed on the source. It can be GET, PUT, POST, DELETE, OPTIONS or HEAD.
  • GET - Used to get information from the server using the provided URI.
  • PUT - Used to replace the existing representation of the target source with the brand-new uploaded data.
  • POST - Used to send data to the server.
  • DELETE - Used to delete the existing representation of the target source.
  • OPTIONS - Used to describe the communication options for the target source.
  • HEAD - Used to get the information from the server. However, it is limited to transferring only the status line and header section.
acceptAccept header as required by the server. Defaults to application/json.
contentTypeThe supported content types are text/plain, text/html, and application/json (Default).
headersIndicate a map of additional http headers to be sent along with the request.
bodyIndicates the request body.
vipAddressWhen using discovery-based service URLs.
  • false to mark status COMPLETED upon execution.
  • true to keep it IN_PROGRESS, wait for an external event (via Conductor or SQS or EventHandler) to complete it.
oauthConsumerKeyOAuth client consumer key.
oauthConsumerSecretOAuth client consumer secret.
connectionTimeOutIndicates the connection time out in milliseconds. If set to 0, it is equivalent to infinity. By default, it is set to 100.
readTimeOutIndicates the read time out in milliseconds. If set to 0, it is equivalent to infinity. By default, it is set to 150.


Let’s see an example workflow:

"name": "your_workflow_name",
"description": "Sample workflow to get started with HTTP POLL task.",
"version": 1,
"tasks": [
"name": "example",
"taskReferenceName": "example",
"inputParameters": {
"http_request": {
"uri": "",
"method": "GET",
"terminationCondition": "1",
"pollingInterval": "60",
"pollingStrategy": "FIXED"
"type": "HTTP_POLL"
"inputParameters": [],
"outputParameters": {},
"schemaVersion": 2,
"ownerEmail": ""

So, here the input parameters for the HTTP_POLL task are defined as follows:

  "terminationCondition": "1",
"pollingInterval": "60",
"pollingStrategy": "FIXED"

The above configuration defines that the conductor will invoke the HTTP API every 60 seconds.