- Introduction
- Getting started
- Process modeling with BPMN
- Process modeling with Case Management
- Designing a persistent case entity schema
- Defining case keys (system vs. external)
- Establishing task I/O and write-back contracts
- Exit rules and early stage termination
- Modeling primary and secondary stages
- Triggering a case from Data Fabric
- Implementing stage-level personas and permissions
- Setting SLAs and automated escalation rules
- Configuring a rework loop (re-entry)
- Managing live case instances: pause, migrate, and retry
- Maestro case management component dictionary
- Process modeling with Flow
- Getting started
- Core concepts
- Node reference
- Build guides
- Best practices
- Reference
- Process implementation
- Debugging
- Simulating
- Publishing and upgrading agentic processes
- Common implementation scenarios
- Extracting and validating documents
- Process operations
- Process monitoring
- Process optimization
- Reference information
Maestro user guide
What it does
Sends an HTTP request to a URL and makes the response available to downstream nodes.
Two HTTP nodes
Flow offers two HTTP nodes. Choose based on how you want to handle authentication:
- HTTP Request (
core.action.http) - Configure the method, URL, headers, body, and authentication inline. Use it for any external REST endpoint where you manage credentials yourself, for example an API key header or a bearer token. This is the node documented on this page. - Managed HTTP Request (
core.action.http.v2) - Makes the request through an Integration Service managed connection, so authentication is handled by that connection rather than configured inline. Use it when you want centralized credential management against a service you've connected through Integration Service.
Configuration reference
| Field | Required | Default | Description |
|---|---|---|---|
| Mode | Yes | Manual | How the request is configured. Select Manual to define the request yourself, or API Definition to import configuration from an OpenAPI or Swagger spec. |
| Import from cURL | No | None | Parses a cURL command and fills in the method, URL, headers, and body automatically. Select the cURL button in the toolbar above the configuration fields. |
| HTTP Method | Yes | GET | HTTP method for the request. Supported values are GET, POST, PUT, PATCH, and DELETE. |
| URL | Yes | None | Full URL to send the request to, including the https:// scheme. Supports variable expressions, for example https://api.example.com/users/$vars.userId. |
| Headers | No | None | Key-value pairs sent as HTTP request headers. Header names and values support variable expressions. |
| Query Parameters | No | None | Key-value pairs appended to the URL as a query string. Names and values support variable expressions. |
| Content Type | No | application/json | Multipurpose Internet Mail Extensions (MIME) type of the request body. Supported values are application/json, application/xml, text/plain, and application/x-www-form-urlencoded. |
| Body | No | Empty | Request body for POST, PUT, and PATCH requests. Enter the value directly in the code editor or use variable expressions. |
| Branches | No | Default output only | Response branches that route the process based on response properties. Each branch has a name and condition expression. |
| Timeout | No | PT15M | Maximum time to wait for a response, in International Organization for Standardization (ISO) 8601 duration format. |
| Retry Count | No | 0 | Number of times to retry the request if it fails. Retries use the timeout value as the backoff interval. |
The editor suggests common header names such as Authorization, Content-Type, Accept, X-Api-Key, and others. For query parameters, adding a parameter with name page and value 2 sends the request to https://api.example.com/items?page=2.
The node evaluates branch conditions in order and follows the first match. If no branch matches, the process follows the Default output.
Branch condition expressions use the same JavaScript syntax as Decision and Switch nodes:
$vars.httpRequest1.output.statusCode === 200
$vars.httpRequest1.output.statusCode === 200
$vars.httpRequest1.output.statusCode >= 400
$vars.httpRequest1.output.statusCode >= 400
Each branch appears as a separate output handle on the right side of the node on the canvas, alongside the Default handle.
Common timeout values:
PT30S- 30 secondsPT5M- 5 minutesPT15M- 15 minutesPT1H- 1 hour
Credentials
You can authenticate requests in two ways.
Manual authentication
Pass credentials directly in request headers. For API key authentication, add a header with name X-Api-Key and value set to your key. For bearer token authentication, add an Authorization header with a value like Bearer <your-token>.
Store sensitive values such as tokens and API keys in secret variables rather than hardcoding them.
Integration Service connector
Select a pre-configured Integration Service connection in the properties panel. The connection injects credentials into the request automatically, so you don't need to manage headers yourself.
Use an Integration Service connector when you want centralized credential management, automatic token refresh, or when multiple processes share the same API credentials.
Integration Service connectors are configured in the UiPath Automation Cloud portal. Refer to the Integration Service documentation for setup instructions.
Examples
Example 1 -- Basic GET request
Fetch a single resource from a public API.
The node is configured with HTTP Method set to GET and URL set to https://jsonplaceholder.typicode.com/posts/1. All other fields remain at their defaults.
The response is available in a downstream Script node:
const body = $vars.httpRequest1.output.body;
const status = $vars.httpRequest1.output.statusCode;
return {
title: body.title,
userId: body.userId,
status: status
};
const body = $vars.httpRequest1.output.body;
const status = $vars.httpRequest1.output.statusCode;
return {
title: body.title,
userId: body.userId,
status: status
};
The response object is available at $vars.httpRequest1.output and contains three fields:
$vars.httpRequest1.output.body- the parsed response body$vars.httpRequest1.output.statusCode- the HTTP status code, for example200$vars.httpRequest1.output.headers- an object containing the response headers
Example 2 -- POST request with a JSON body
Create a new resource by sending a JSON payload.
The node is configured with HTTP Method set to POST, URL set to https://api.example.com/orders, an Authorization header with value Bearer $vars.apiToken, and Content Type left as application/json. The body:
{
"product": "Widget",
"quantity": 5,
"customer_id": "cust_12345"
}
{
"product": "Widget",
"quantity": 5,
"customer_id": "cust_12345"
}
The created resource's ID is available in a downstream node:
const orderId = $vars.httpRequest1.output.body.id;
return { orderId: orderId };
const orderId = $vars.httpRequest1.output.body.id;
return { orderId: orderId };
If the request fails and you've connected an error handle, the error details are available at $vars.httpRequest1.error:
// In a Script node connected to the error handle
const errorMessage = $vars.httpRequest1.error.message;
const errorStatus = $vars.httpRequest1.error.status;
return {
failed: true,
reason: errorMessage,
httpStatus: errorStatus
};
// In a Script node connected to the error handle
const errorMessage = $vars.httpRequest1.error.message;
const errorStatus = $vars.httpRequest1.error.status;
return {
failed: true,
reason: errorMessage,
httpStatus: errorStatus
};
The error object contains:
codemessagedetailcategorystatus
Example 3 -- Route responses with branches
Response branches let the process follow different paths based on the API's response without a separate Decision node.
The node is configured with HTTP Method set to GET, URL set to https://api.example.com/users/$vars.userId, and two branches in the Branches section: Success with condition $vars.httpRequest1.output.statusCode === 200 and Not Found with condition $vars.httpRequest1.output.statusCode === 404.
The node now has three output handles on the canvas:
- Success - connects to nodes that process the user data
- Not Found - connects to nodes that handle the missing user case
- Default - connects to a fallback path for any other status code
Each downstream path receives the full response. For example, on the Success branch:
const user = $vars.httpRequest1.output.body;
return { name: user.name, email: user.email };
const user = $vars.httpRequest1.output.body;
return { name: user.name, email: user.email };
When to use this vs an integration node
Use the HTTP Request node as a general-purpose tool for calling any API. Use a dedicated integration node when one exists for the service you're calling.
| Use HTTP Request when... | Use an integration node when... |
|---|---|
| The API has no dedicated connector in the node palette | A connector exists for the service, such as Slack, Salesforce, or HubSpot |
| You need full control over headers, query parameters, and body format | You want pre-built typed inputs and outputs with no manual configuration |
| You're prototyping against a new API or internal service | You want automatic authentication and token refresh via Integration Service |
| The API uses a non-standard authentication scheme | You want a maintainable process that won't break if the API changes its contract |
Rule of thumb: Search the node palette for a connector first. Fall back to HTTP Request only if nothing exists for your target service.
Related pages
- Script node - transform and process HTTP response data
- Decision node - branch on conditions, as an alternative to response branches
- Variables and data flow -
$vars, expression syntax, and variable scoping