> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/continuous-delivery/use-continuous-delivery/cd-building-blocks/cd-steps/utilities/http-step.md).

# HTTP step

This topic describes the settings for the HTTP step.

You can use the HTTP step to run HTTP methods containing URLs, methods, headers, assertions, and variables.

### Basic settings in the HTTP step <a href="#basic-settings-in-the-http-step" id="basic-settings-in-the-http-step"></a>

The following list covers the step settings.

* Name: The name of the step. You'll use this name when you reference the step settings. For example, if the step name is HTTP and you want to reference the URL entered in its **URL** setting, use: `<+pipeline.stages.tooltips.spec.execution.steps.HTTP.spec.url>`.
* Timeout: The timeout for the step. Timeouts can be set at the pipeline level also.
* URL: The URL for the HTTP call.
* Method: The [HTTP method](https://restfulapi.net/http-methods/#summary) to use in the step.
* Request body: The message body of the HTTP message.

{% hint style="info" %}
**IMPORTANT**

Currently, Harness doesn't support using secret expressions as part of URLs in HTTP steps.
{% endhint %}

### Assertions in the HTTP step <a href="#assertions-in-the-http-step" id="assertions-in-the-http-step"></a>

**Assertion** is used to validate the incoming response. For example, if you wanted to check the health of an HTTP connection, use the assertion `<+httpResponseCode>==200`.

The expression `<+httpResponseCode>==200` will evaluate to true if the HTTP call returns a 200 code. You can also use the reverse expression `200==<+httpResponseCode>`.

Expressions can use the following aliases to refer to the HTTP responses, URL, and method.

* `<+httpResponseCode>`
* `<+httpUrl>`
* `<+httpMethod>`
* `<+httpResponseBody>`

#### String assertions in the HTTP step <a href="#string-assertions-in-the-http-step" id="string-assertions-in-the-http-step"></a>

To assert using strings in expressions, use double quotes. Without double quotes, JEXL mistakes the assertions as an expression.

Here are some examples:

* Correct: `"<+pipeline.variables.var1>"=="http"`.
* Incorrect: `<+pipeline.variables.var1>==http`.

#### Integer assertions in the HTTP step <a href="#integer-assertions-in-the-http-step" id="integer-assertions-in-the-http-step"></a>

Assertions using integers should be done without any quotes because both sides of the JEXL assertion should use a number format.

Here are some examples:

* Correct: `<+pipeline.variables.EXPECTED_RESPONSE>==<+httpResponseCode>`.
* Incorrect: `<+pipeline.variables.EXPECTED_RESPONSE>"=="<+httpResponseCode>`.

#### Assertion failures and failure strategies <a href="#assertion-failures-and-failure-strategies" id="assertion-failures-and-failure-strategies"></a>

Step failures are grouped into several categories, such as **Authentication Errors**, **Timeout Errors**, etc. When you set up a stage or step failure strategy, you can select which error category initiates the strategy.

For HTTP assertions, the **Unknown Errors** category initiates the strategy.

If you want a failure strategy to run when the HTTP step assertion fails, in the HTTP step **Advanced Settings**, **Failure Strategy**, in **On failure of type**, select **Unknown Errors** and then define your strategy.

When an assertion fails

### Headers in the HTTP step <a href="#headers-in-the-http-step" id="headers-in-the-http-step"></a>

Enter the media type for the message. For example, if you are using the GET method, the headers are used to specify the GET response body message type.

1. In **Key**, enter `Token`
2. In **Value**, enter `<+secrets.getValue("aws-playground_AWS_secret_key")>`

Another method:

* **Key**: `variable:`
* **Value**: `var1,var2:var3`

You can copy the key and paste it in the HTTP step **Header** setting. For more information, go to [Manage API keys](/harness-ai/use-harness-platform/automation/api/add-and-manage-api-keys.md).

### Input variables in the HTTP step <a href="#input-variables-in-the-http-step" id="input-variables-in-the-http-step"></a>

Create input variables that can be used by other fields within the step. The **Value** setting can contain fixed values, expressions, or runtime inputs.

These variables can be used by other fields like URLs by using the following expressions:

`<+spec.inputVariables.variable_name>` or `<+step.spec.inputVariables.variable_name>`

![](/files/9R8z8rYbkQI78mIqCdwo)

### Output variables in the HTTP step <a href="#output-variables-in-the-http-step" id="output-variables-in-the-http-step"></a>

Create output variables to be used by other steps in the stage. The **Value** setting can contain any HTTP step input, output, or response information.

You can also use ​JSON and XML functors in the values for the output variable. For example, `<+json.select("data.attributes.version_pins.mvn-service://new-construction-api", httpResponseBody)>`.

You can use pipeline variables along with `httpResponseBody` and `httpResponseCode`.

Here are some examples:

`<+json.object(httpResponseBody).title>`

`<+json.select(<+pipeline.variables.title>, httpResponseBody)>`

To concatenate strings within the JSON functor:

`<+json.select(<+ <+pipeline.variables.user> + <+pipeline.variables.id>>,httpResponseBody)>` or `<+json.select("user".concat(<+pipeline.variables.id>),httpResponseBody)>`

For more information, go to [JSON and XML functors](/continuous-delivery/use-continuous-delivery/cd-building-blocks/cd-steps/utilities/json-and-xml-functors.md).

Output variables also support [JEXL expressions](https://commons.apache.org/proper/commons-jexl/reference/syntax.html).

### Advanced step settings <a href="#advanced-step-settings" id="advanced-step-settings"></a>

In **Advanced**, you can use the following options:

* [Delegate Selector](/harness-ai/use-harness-platform/delegates/delegate/manage-delegates/select-delegates-with-selectors.md)
* [Conditional Execution](/harness-ai/use-harness-platform/pipelines/step-skip-condition-settings.md)
* [Failure Strategy](/harness-ai/use-harness-platform/pipelines/failure-handling/define-a-failure-strategy-on-stages-and-steps.md)
* [Looping Strategy](/harness-ai/use-harness-platform/pipelines/looping-strategies/looping-strategies-matrix-repeat-and-parallelism.md)
* [Policy Enforcement](/harness-ai/use-harness-platform/governance/policy-as-code/harness-governance-overview.md)

### Step execution inputs and outputs <a href="#step-execution-inputs-and-outputs" id="step-execution-inputs-and-outputs"></a>

Once you execute your pipeline, the step displays its inputs and outputs and their values.

![](/files/SrPvivcEGi4zRa2A9lEl)

You can reference these anywhere in your pipeline.

#### Inputs <a href="#inputs" id="inputs"></a>

In the following examples, the Id of the HTTP step is `HTTP`.

| **Input Name** | **Input Reference Example**                                                    | **Input Value Example**            |
| -------------- | ------------------------------------------------------------------------------ | ---------------------------------- |
| identifier     | `<+pipeline.stages.HTTP.spec.execution.steps.check_response.identifier>`       | `check\_response`                  |
| name           | `<+pipeline.stages.HTTP.spec.execution.steps.check_response.name>`             | `check response`                   |
| timeout        | `<+pipeline.stages.HTTP.spec.execution.steps.check_response.timeout>`          | `10s`                              |
| type           | `<+pipeline.stages.HTTP.spec.execution.steps.check_response.type>`             | `Http`                             |
| url            | `<+pipeline.stages.HTTP.spec.execution.steps.check_response.spec.url>`         | `https://www.google.com/search?q=` |
| method         | `<+pipeline.stages.HTTP.spec.execution.steps.check_response.spec.method>`      | `GET`                              |
| requestBody    | `<+pipeline.stages.HTTP.spec.execution.steps.check_response.spec.requestBody>` | `current+date`                     |
| assertion      | `<+pipeline.stages.HTTP.spec.execution.steps.check_response.spec.assertion>`   | `<+httpResponseCode> == 200`       |

#### Outputs <a href="#outputs" id="outputs"></a>

In the following examples, the Id of the HTTP step is `HTTP`.

| **Output**       | **Output Reference Example**                                                | **Output Value Example**           |
| ---------------- | --------------------------------------------------------------------------- | ---------------------------------- |
| httpUrl          | `<+pipeline.stages.HTTP.spec.execution.steps.HTTP.output.httpUrl>`          | `https://www.google.com/search?q=` |
| httpMethod       | `<+pipeline.stages.HTTP.spec.execution.steps.HTTP.output.httpMethod>`       | `GET`                              |
| httpResponseCode | `<+pipeline.stages.HTTP.spec.execution.steps.HTTP.output.httpResponseCode>` | `200`                              |
| httpResponseBody | `<+pipeline.stages.HTTP.spec.execution.steps.HTTP.output.httpResponseBody>` | `Hello`                            |
| status           | `<+pipeline.stages.HTTP.spec.execution.steps.HTTP.output.status>`           | `SUCCESS`                          |

### Use a certificate and key <a href="#use-a-certificate-and-key" id="use-a-certificate-and-key"></a>

{% hint style="info" %}
**IMPORTANT**

This feature requires Harness Delegate version 82400 or later.
{% endhint %}

You can specify a TSL certificate and key for the HTTP step. This enables TLS encryption for your HTTP services.

1. In **Optional Configuration**, in **Certificate**, select the secret for the certificate, including the `-----BEGIN CERTIFICATE-----` and `-----END CERTIFICATE-----`.
2. In **Certificate Key**, select the secret for the public key.

You can use fixed values, expressions, or runtime inputs for these settings. For more information, go to Harness [file secrets](/harness-ai/use-harness-platform/secrets/secrets-management/harness-secret-manager-overview.md) and [text secrets](/harness-ai/use-harness-platform/secrets/add-use-text-secrets.md).

{% hint style="info" %}
Certification validation is disabled for this step.
{% endhint %}

### Delegate proxy <a href="#delegate-proxy" id="delegate-proxy"></a>

HTTP step supports delegate proxy settings by default. For more information, go to [delegate proxy settings](/harness-ai/use-harness-platform/delegates/delegate/manage-delegates/configure-delegate-proxy-settings.md).

### Header capability check <a href="#header-capability-check" id="header-capability-check"></a>

When Harness runs an HTTP step and connects to a service, it checks to make sure that an HTTP connection can be established.

Some services require HTTP headers to be included in connections. Without the headers, the HTTP connections fail and simple HTTP verification cannot be performed.

Harness performs an HTTP capability check with the headers included on the target service.

If the target host server require headers and you do not include headers in the **Headers** setting of the HTTP step, the Harness Delegate will fail the deployment with the error `No eligible delegates could perform this task` (`error 400`).

Add the required headers in **Headers** and run the deployment. Adding the headers will prevent the `400` error.

Harness secrets are not used during capability checks. They are used in actual steps only. If you have a step configured with URLs and multiple headers like:

`x-api-key : <+secret.getValue('apikey')>`\
`content-type : application/json`

During a capability check, the non-secret headers are used as is but the secret headers are masked. Harness makes the HTTP request with the URL and headers as follows:

`x-api-key:<<<api_key>>>`\
`content-type:application/json`

This results in a `401 Unauthorized` response due to an incorrect api key. However, the capability check will be successful and the task will be assigned to the Harness Delegate.

{% hint style="info" %}
Using `<<<and>>>` in HTTP requests might result in bad requests on the server side. In such cases, follow this workaround.

* Use Shell script to run cURL command and manually process the response.
  {% endhint %}

Capability checks are basic accessibility checks and do not follow multiple redirects. Hence, Harness returns from the first `302 Found` response during capability checks.

{% hint style="info" %}
You can enable **Ignore status code for HTTP connections**. When enabled, Harness only requires a valid response from the target HTTP server and does not verify the response code. This is particularly useful when the Harness Delegate is configured with a proxy because socket connection tests conducted by Harness from the delegate do not account for proxy details.

This setting is only relevant for HTTP steps and HTTP Helm repositories.

`Please note this setting can be enabled at Organization,Account as well as Project Level.`

In this example, we will be discussing the process of enabling this setting at the project level.

You can enable the setting by using the steps below:

1. Enable the setting by navigating to **Project Settings**.
2. Select **Default Settings** under **General**.
3. Under **Continuous Deployment**, you can set **Ignore status code for HTTP connections** as **true**.
   {% endhint %}

### HTTP polling <a href="#http-polling" id="http-polling"></a>

The HTTP step supports polling. When you create the HTTP step for polling, the client requests the resource at regular intervals.

To configure polling in the HTTP step:

1. In the step, go to **Step Parameters** > **Optional Configuration**, and enter the following details:
   * **Assertion (optional)**: Enter the expression to validate the incoming response. You can use the following aliases to refer to the HTTP responses, URL, and method:
     * `<+httpsResponseCode>`
     * `<+httpUrl>`
     * `<+httpMethod>`
     * `<+httpResponseBody>`
   * **Headers (optional)**: Enter the key and value for the headers in the message.

     For example, in **Key**, enter the token, in **Value**, enter secret references such as `<+secrets.getValue("aws-playground_AWS_secret_key")>`.
   * **Output (optional)**: Create the output steps to be used by other steps in the stage.

     The **Value** setting can contain any HTTP step input, output, or response information. You can also use JSON and XML functors in the value.
2. In **Advanced** > **Failure Strategy**, do the following:

   * In **On failure of type**, select **All Errors**.
   * In **Perform Action**, select **Retry**.
   * In **Retry count**, enter the number of times you want the HTTP step to retry reaching the resource.
   * In **Retry intervals**, specify the gap between two successive connection retries.
   * In **Post retry failure action**, select **Ignore Failure**.

   ![](/files/pDL1RlxUcszbTXp3Wu1o)

The HTTP step retries polling and ignores all errors until the condition mentioned in the assertion section is met.

### Using HTTP requests in CD pipelines <a href="#using-http-requests-in-cd-pipelines" id="using-http-requests-in-cd-pipelines"></a>

This section provides examples on how to use the HTTP step.

You can use the HTTP step to run HTTP methods containing URLs, methods, headers, assertions, and variables. It helps you avoid having script cURL commands for simple REST calls.

The most common use of the HTTP step is to run a health check post-deployment. For example, make sure that an HTTP or IP endpoint, such as a load balancer, is properly exposed.

Other common uses are:

* Making a call to a third-party system to gather deployment information, such as a Nexus IQ scan.
* Open Policy Agent (OPA) policy agent call.
* General HTTP testing calls to the deployed application.

Go to [Harness REST API quickstart](/harness-ai/use-harness-platform/automation/api/api-quickstart.md) for more information.

#### Add the HTTP step <a href="#add-the-http-step" id="add-the-http-step"></a>

You can add the HTTP step to any CD Pipeline stage independent of deployment strategy.

1. In your Harness pipeline stage, in **Execution**, select **Add Step**.
2. Select **HTTP**. The HTTP step appears.

![](/files/HXuEO4qVn3VJaJs9LJ4b)

#### Name and Timeout <a href="#name-and-timeout" id="name-and-timeout"></a>

1. Enter a name for the step.

   Harness automatically creates an **Id**. You'll use this Id to reference this step's settings in other steps.

   For example, if the stage name is **dev** and the step Id is **HTTP** and you want to reference the URL entered in its **URL** setting, you'd use:

   `<+pipeline.stages.dev.spec.execution.steps.HTTP.spec.url>`
2. In **Timeout**, enter a timeout for this step.You can use:

   * `w` for weeks
   * `d` for days
   * `h` for hours
   * `m` for minutes
   * `s` for seconds
   * `ms` for milliseconds

   The maximum is `53w`.Timeouts are set at the Pipeline level also.

#### URL for HTTP call <a href="#url-for-http-call" id="url-for-http-call"></a>

In **URL**, enter a URL for the call. It must include the `http://` scheme.

For more information on runtime inputs and expressions, go to [Fixed values runtime inputs and expressions](/harness-ai/use-harness-platform/variables-and-expressions/runtime-inputs.md)..

You can use [Harness variables](/harness-ai/use-harness-platform/variables-and-expressions/harness-variables.md) too. For example, if the Service name matches the domain name of the HTTP address, you can use `http://<+service.name>/...`.

Before handing the execution of the HTTP step to a Harness Delegate, Harness performs a capability check on the URL to ensure that a non-400 response code is returned.

#### Character encoding <a href="#character-encoding" id="character-encoding"></a>

{% hint style="info" %}
Currently, character encoding is behind the feature flag `CDS_ENCODE_HTTP_STEP_URL`. Contact [Harness Support](mailto:support@harness.io) to enable the feature.
{% endhint %}

By default, Harness validates the URL you enter to ensure it is not an invalid URL (or a URL with invalid characters) before it sends the request to the URL.

Harness can allow URLs with invalid characters such as a blank space, `^`, `{`, `}` and URL encode them before sending the request.

#### HTTP method <a href="#http-method" id="http-method"></a>

In HTTP Method, select the method for the call.

Harness supports the following [HTTP methods](https://restfulapi.net/http-methods/#summary):

* GET
* POST
* PUT
* DELETE
* HEAD
* OPTIONS

#### Request Body <a href="#request-body" id="request-body"></a>

In Request **Body**, enter the body of the HTTP payload to send to the URL.

You can use a **Fixed Value**, **Runtime Input**, or **Expression**.

You can use [Harness variables](/harness-ai/use-harness-platform/variables-and-expressions/harness-variables.md) too. For example, if the Service name matches the domain name of the HTTP address, you can use `http://<+service.name>/...`.

Before handing the execution of the HTTP step to a Harness Delegate, Harness performs a capability check on the URL to ensure that a non-400 response code is returned.

#### Assertion <a href="#assertion" id="assertion"></a>

The assertion is used to validate the incoming response. For example, if you wanted to check the health of an HTTP connection, you could use the assertion `<+httpResponseCode> == 200`.

The expression `<+httpResponseCode> == 200` will evaluate to true if the HTTP call returns a 200 code.

Expressions can use the following aliases to refer to the HTTP responses, URL, and method:

* `<+httpResponseCode>`
* `<+httpUrl>`
* `<+httpMethod>`
* `<+httpResponseBody>`

#### String assertions in the HTTP step <a href="#string-assertions-in-the-http-step" id="string-assertions-in-the-http-step"></a>

To assert using strings in expressions, use double quotes. Without double quotes, JEXL mistakes the assertions as an expression.

Here are some examples:

* Correct: `"<+pipeline.variables.var1>"=="http"`.
* Incorrect: `<+pipeline.variables.var1>==http`.

#### Integer assertions in the HTTP step <a href="#integer-assertions-in-the-http-step" id="integer-assertions-in-the-http-step"></a>

Assertions using integers should be done without any quotes because both sides of the JEXL assertion should use a number format.

Here are some examples:

* Correct: `<+pipeline.variables.EXPECTED_RESPONSE>==<+httpResponseCode>`.
* Incorrect: `<+pipeline.variables.EXPECTED_RESPONSE>"=="<+httpResponseCode>`.

You can use a Fixed Value, Runtime Input, or Expression.

You can use [Harness variables](/harness-ai/use-harness-platform/variables-and-expressions/harness-variables.md) too.

#### Headers <a href="#headers" id="headers"></a>

Headers are `key:value` pairs. For example:

* `Content-Type: application/json`
* `Content-Type: text/html`

You can use a Fixed Value, Runtime Input, or Expression.

You can use [Harness variables](/harness-ai/use-harness-platform/variables-and-expressions/harness-variables.md) too.

You can reference [Harness secrets](/harness-ai/use-harness-platform/secrets/add-use-text-secrets.md) in the **Value** setting too.

For example, in **Key**, enter `Token`.

In **Value**, enter `<+secrets.getValue("aws-playground_AWS_secret_key")>`.

#### Output variables <a href="#output-variables" id="output-variables"></a>

You can create output variables and reference them in other steps in the stage. The **Value** setting can contain any HTTP step input, output, or response information.

To reference the value of the output variable in another step using its fully-qualified name (FQN).

For example, here's a variable `example` with the value `1234`. The step name is `GET`.

![](/files/uio1AAceX6Xm9OCuq4ch)

Save the step and then click **Variables**.

1. In the **Variables** drawer, copy the **example** variable.
2. In another step, like a **Shell Script** step, paste the FQN.

The FQN will resolve to the variable value at execution runtime.

You can also use ​JSON and XML functors in the values for the output variable. For example, `<+json.select("data.attributes.version_pins.mvn-service://new-construction-api", httpResponseBody)>`.

See [JSON and XML functors](/continuous-delivery/use-continuous-delivery/cd-building-blocks/cd-steps/utilities/json-and-xml-functors.md).

### Accessing HTTP Response Headers <a href="#accessing-http-response-headers" id="accessing-http-response-headers"></a>

{% hint style="info" %}
This feature is currently behind the feature flag `CDS_SUPPORT_HTTP_HEADER_HTTP_STEP`. Contact [Harness Support](mailto:support@harness.io) to enable it.
{% endhint %}

You can now access HTTP response headers—such as cookies—directly within your pipeline using the expression: `<+httpResponseHeaders.get('headerKey')>`

Replace `'headerKey'` with the specific header you want to retrieve (e.g., `'set-cookie'`, `'content-type'`, or `'x-api-key'`).

This expression can be used in:

* **Output variables**
* **Step conditions**
* **Assertions**\
  Example: `<+httpResponseHeaders.get('status-code')> == 400`

#### Security Considerations <a href="#security-considerations" id="security-considerations"></a>

* **Header values are not printed in logs** to protect sensitive data.
* **Only header names are shown** in logs.
* **All header names are normalized to lowercase**\
  (e.g., `'Content-Type'` becomes `'content-type'`).

However, full header details—including values—are available in the **step output section** in the Harness UI.

### Simulate load by running steps in parallel <a href="#simulate-load-by-running-steps-in-parallel" id="simulate-load-by-running-steps-in-parallel"></a>

You can use multiple HTTP steps in parallel to simulate load.

Create a step group and add multiple HTTP steps with the same URL pointing to your service.

![](/files/I9PomI8Vtx3mIDfLrcN2)

The steps are executed in parallel and simulate load.

You can add multiple steps to the group quickly using YAML. Just paste additional steps into the Step Group. Be sure to rename each step. Here's an example:

```yaml
...  
- stepGroup:  
  name: Simulate Load  
  identifier: Simulate_Load  
  steps:  
      - parallel:  
            - step:  
                  type: Http  
                  name: Load 1  
                  identifier: Load_1  
                  spec:  
                      url: http://example.com  
                      method: GET  
                      headers: []  
                      outputVariables: []  
                  timeout: 10s  
            - step:  
                  type: Http  
                  name: Load 2  
                  identifier: Load_2  
                  spec:  
                      url: http://example.com  
                      method: GET  
                      headers: []  
                      outputVariables: []  
                  timeout: 10s  
            - step:  
                  type: Http  
                  name: Load 3  
                  identifier: Load_3  
                  spec:  
                      url: http://example.com  
                      method: GET  
                      headers: []  
                      outputVariables: []  
                  timeout: 10s  
  failureStrategies: []  
  spec: {}  
...
```

### See also <a href="#see-also" id="see-also"></a>

* [Shell Script step](/continuous-delivery/use-continuous-delivery/cd-building-blocks/cd-steps/utilities/shell-script-step.md)
* [JSON and XML functors](/continuous-delivery/use-continuous-delivery/cd-building-blocks/cd-steps/utilities/json-and-xml-functors.md)