# HTTP Request The HTTP Request node in Aisera Workflow Studio enables your automation workflows to send outbound HTTP requests to external APIs and web services. Use this node to integrate with REST APIs, fetch data from external systems, send notifications, or trigger actions in third-party applications. The example below shows the configuration for an HTTP Node that will query the FedEx website to track real time updates to a package based on transaction id.
### How to Configure the HTTP Request Node: 1. Add the node to your workflow by dragging it from the **Node Palette** onto the **AI Workflow Studio Canvas**. 2. Click the node to open the **Configuration** dialog. 3. Fill in the required fields: 1. Enter the target URL. 2. Select the HTTP method. 3. Configure the headers (if needed). 4. Set the timeout values. 5. Define response variable names. 4. Test the configuration before deploying. 5. Save and connect the node to subsequent workflow steps. ### Configuration Parameters Use the following tables to learn about the required fields, optional fields, and parameters. #### Required Fields
Required FieldDescriptionExample
URLThe endpoint URL for the HTTP request. Variables can be used in URL query parameters in the form ${varName}.https://api.example.com/users?id=${userId}
MethodThe HTTP method to use for the request.GET, POST, PUT, DELETE, PATCH
#### Optional Fields | Optional Field | Description | Default | Notes | | ----------------------------- | ------------------------------------------------------------------------------- | -------------- | -------------------------------------------------------------- | | Headers | Key-value pairs for HTTP headers. Click **Add Header** to add multiple headers. | None | Common headers include Content-Type, Authorization, Accept | | Connection Timeout in seconds | Maximum time to wait for connection establishment. | System default | Prevents indefinite waiting for unresponsive endpoints | | Read Timeout in seconds | Maximum time to wait for response data after connection. | System default | Use higher values for slow APIs | | Write Timeout in seconds | Maximum time allowed for sending request data. | System default | Important for large payloads | | Response | Variable name to store the response body. | None | Access later in workflow using `${responseName}` | | Status | Variable name to store the HTTP status code. | None | Used for conditional logic (fore exampld, check if equals 200) | | Response Headers | Variable name to store response headers. | None | Useful for extracting metadata from responses | | Node Description | Custom description for this node instance. | None | Helps document your workflow logic | ### Using Variables The HTTP Request node supports dynamic values using the `${varName}` syntax\[1]. #### URL Parameters `https://api.example.com/users?userId=${userId}&action=${actionType}` #### Request Body When using POST or PUT methods, you can include variables in the request body: ```json { "name": "${userName}", "email": "${userEmail}", "status": "active" } ``` ### Common Use Cases Review the use cases below to get an idea of what your HTTP call needs to contain. #### Example 1: Fetching User Data (GET Request) Configuration: * URL: `https://api.crm.com/users/${userId}` * Method: GET * Headers: * Name: Authorization * Value: Bearer `${apiToken}` * Response: userData * Status: httpStatus Usage in workflow: Access the response with `${userData}` in subsequent nodes\[1]. #### Example 2: Creating a New Record (POST Request) Configuration: * URL: `https://api.example.com/tickets` * Method: POST * Headers: * Name: Content-Type * Value: application/json * Name: Authorization * Value: Bearer `${apiToken}` * Request Body: ```json { "title": "${ticketTitle}", "description": "${ticketDescription}", "priority": "high" } ``` * Response: createTicketResponse * Status: createStatus #### Example 3: Updating Data (PUT Request) Configuration: * URL: `https://api.example.com/users/${userId}` * Method: PUT * Headers: * Name: Content-Type * Value: application/json * Connection Timeout: 10 * Read Timeout: 30 ### HTTP Methods Reference The Aisera Gen AI platform supports the following HTTP calls. | Method | Purpose | Has Body | | ------ | -------------------------------------------- | -------- | | GET | Retrieve data from a server | No | | POST | Create new resources | Yes | | PUT | Update existing resources (full replacement) | Yes | | PATCH | Partial update of resources | Yes | | DELETE | Remove resources | Optional | ### Headers Configuration The following table contains commonly used headers: | Hearder Name | Purpose | Example | | ------------- | ------------------------------- | ------------------------------------------- | | Content-Type | Specify request body format | application/json | | Authorization | Authenticate with API | Bearer `${token}` or Basic `${credentials}` | | Accept | Specify desired response format | application/json | | User-Agent | Identify the client | AiseraWorkflow/1.0 | | X-API-Key | API key authentication | `${apiKey}` | To add multiple headers, click the "Add Header" button and enter each key-value pair. ### Timeout Configuration The following timeout configurations are supported. #### Connection Timeout Time allowed to establish a connection with the server. If the server doesn't respond within this time, the request fails. Recommended: 5-10 seconds for most APIs. #### Read Timeout Time allowed to read the response after connection is established. Set higher values for APIs that perform complex processing. Recommended: 30-60 seconds for standard APIs, up to 120 seconds for slow endpoints. #### Write Timeout Time allowed to send the request body to the server. Important when sending large payloads. Recommended: 30-60 seconds for standard requests. ### Working with Responses After the HTTP Request node executes, you can access the stored response in subsequent nodes: * Response Body: `${responseName}` - Contains the full response data * Status Code: `${statusName}` - HTTP status code (e.g., 200, 404, 500) * Response Headers: `${responseHeadersName}` - All headers returned by the server #### Example: Conditional Logic Based on Status Use the stored status code in a Decision node: If `${httpStatus}` equals 200, proceed with success path If `${httpStatus}` equals 404, handle "not found" scenario If `${httpStatus}` equals 500, handle error ### Error Handling and Troubleshooting The following sections include Return Status Codes, Troubleshooting Tips, and Best Practices. #### Common HTTP Status Codes | Status Code | Meaning | What to Check | | ------------------------- | ----------------------------- | --------------------------------------------- | | 200 OK | Request succeeded | Continue with workflow | | 201 Created | Resource created successfully | Verify response contains new resource ID | | 400 Bad Request | Invalid request format | Check request body syntax and required fields | | 401 Unauthorized | Authentication failed | Verify Authorization header and credentials | | 403 Forbidden | No permission to access | Check API permissions and access rights | | 404 Not Found | Resource doesn't exist | Verify URL and resource ID | | 429 Too Many Requests | Rate limit exceeded | Implement retry logic with delays | | 500 Internal Server Error | Server-side error | Contact API provider or retry later | | 503 Service Unavailable | Service temporarily down | Implement retry logic | #### Troubleshooting Tips 1. Connection Timeout Errors 2. Check if the URL is correct and accessible 3. Verify network connectivity 4. Increase connection timeout value 5. Read Timeout Errors 6. The API may be processing slowly 7. Increase read timeout value 8. Check API status/performance 9. Authentication Failures (401/403) 10. Verify Authorization header is properly formatted 11. Check if API token/key is valid and not expired 12. Ensure proper variable substitution: `${tokenVar}` 13. Bad Request Errors (400) 14. Validate JSON syntax in request body 15. Verify all required fields are included 16. Check data types match API requirements 17. Variable Not Substituting 18. Ensure variable name matches exactly: `${varName}` 19. Verify the variable exists in workflow context 20. Check variable is set before HTTP Request node executes ### Best Practices 1. **Use Descriptive Variable Names:** Name response variables clearly (for example, userDataResponse, createTicketStatus). 2. **Always Capture Status Codes:** Store the status code to implement proper error handling logic. 3. **Set Appropriate Timeouts:** Don't use excessively long timeouts; they can slow down your workflow. 4. **Secure Credentials:** Use workflow variables or secrets management for API keys and tokens, never hardcode them. 5. **Test Endpoints First:** Use tools like Postman or curl to verify the API works before configuring in the workflow. 6. **Add Node Descriptions:** Document what each HTTP Request node does using the Node Description field for future reference. 7. **Handle Errors Gracefully:** Always add error handling logic after HTTP Request nodes to manage failures. 8. **Use Content-Type Headers:** Always specify Content-Type: application/json when sending JSON payloads. ### Advanced Configuration #### Dynamic URLs with Multiple Variables `https://api.example.com/${version}/users/${userId}/orders/${orderId}` #### Passing Arrays in Query Parameters `https://api.example.com/search?tags=${tag1}&tags=${tag2}&tags=${tag3}` #### Working with Response Arrays If the API returns an array, you can iterate over it using a Loop node in your workflow after the HTTP Request. ### Related Workflow Nodes * **Decision Node:** Use to check HTTP status codes and branch workflow logic * **Loop Node:** Iterate over array responses from APIs * **JSON Parser Node:** Parse and extract specific fields from JSON responses * **Error Handler Node:** Catch and handle HTTP request failures ***