--- title: "Workflow: Make HTTP Request Action" slug: "workflow-make-http-request-action" updated: 2026-06-04T14:36:18Z published: 2026-06-04T14:36:18Z canonical: "help.idibilling.com/workflow-make-http-request-action" --- > ## Documentation Index > Fetch the complete documentation index at: https://help.idibilling.com/llms.txt > Use this file to discover all available pages before exploring further. # Workflow: Make HTTP Request Action ## Overview The Make HTTP Request action will perform an HTTP(S) request from the Workflow system to a specified address. It allows you to specify the method, the body of the request, as well as any desired HTTP headers. Using the Make HTTP Request action, you can: - Easily integrate with CostGuard APIs - Integrate with arbitrary third-party APIs - Achieve greater flexibility than the existing Web API action ## Action Parameters | Parameter Name | Required? | Description | | --- | --- | --- | | Address | Yes | The address to which the HTTP request should be made | | Method | Yes | The HTTP method to use when making the request. Supported methods are: GET, DELETE, PATCH, POST, PUT. | | Include IDI Security Token | No | If set to “Yes”, the request send will include an `Authorization` header that specifies a token that will allow integration with other CostGuard APIs. *Note that this will take precedence over the Authorization parameter, as well as any “Authorization” headers specified in Additional Headers.* | | Authorization | No | The value specified here will be sent as the value of the `Authorization` header in the request. *Note that this will take precedence over any “Authorization” headers specified in Additional Headers.* | | Content-Type | No | The value specified here will be sent as the value of the `Content-Type` header in the request. | | Additional Headers | No | A JSON object that represents any additional headers to be sent in the request. (The keys of the object should be the name of the HTTP header, the values should be the value of the header.) | | Body | No | The body of the request. | ## Examples ### Use in a Workflow Instance: Interact with an external system at a certain point in a Workflow instance In this example, we’ll assume we have a Workflow for managing the flow of a new employee hire. After the employee has completed security training, we want to create a record for the employee in an external security system. We can do this by adding a task to perform the Make HTTP Request Action. Assume we have the following: - The security system allows creating employee records with the following address: `https://security.mycompanyapis.com/api/employee`. The request should be a POST and specify at least `employeeId` and `employee` name in a JSON body. - Our Workflow has two pieces of extended data, `Employee ID` and `Employee Name` that we want to use in the request to the third-party system. - We need to supply a token in the Authorization header: `MySecurityToken`. With this information, we can configure a task in our Workflow with the Make HTTP Request action with the following parameters: ![](https://cdn.us.document360.io/3f7f8ade-bcb1-4ec8-af25-0c0ad8601afb/Images/Documentation/MakeHTTPRequest.png?sv=2026-02-06&spr=https&st=2026-11-14T10%3A47%3A37Z&se=2026-11-14T11%3A47%3A37Z&sr=c&sp=r&sig=LirrPZYlbPzTSH2R%2BS00pyhL97JwzZCvRZRu2TmbmP0%3D) ### Use in a Trigger: Sync customer data when changed In this example, we’ll assume that we have an external system for managing customer information, and we would like to keep it in sync when customer data in CostGuard changes. We can do this using a combination of the Customer Modified trigger and the Make HTTP Request action. Assume we have the following: - The external customer system allows modifying customer records with the following address: `https://customer.mycompanyapis.com/api/customer/{id}`. The request should be a PATCH, and specify a JSON object as the body that contains new values for properties that should be changed. - We need to supply a token in the Authorization header: `MySecurityToken`. - We only care (for this example) about syncing the customer’s name. We can configure the trigger as such: ![](https://cdn.us.document360.io/3f7f8ade-bcb1-4ec8-af25-0c0ad8601afb/Images/Documentation/Trigger.png?sv=2026-02-06&spr=https&st=2026-11-14T10%3A47%3A37Z&se=2026-11-14T11%3A47%3A37Z&sr=c&sp=r&sig=LirrPZYlbPzTSH2R%2BS00pyhL97JwzZCvRZRu2TmbmP0%3D) ## Response Handling ### Timeout The Make HTTP Request action is configured to have a two minute timeout. ### Status Codes Depending on the returned HTTP status code, different actions will be performed. | Status Code | Description | Result | Action | | --- | --- | --- | --- | | `2XX` | Any status code between 200 and 299 | Success | **If used in a task**: the task will be completed. **If used in a trigger**: no action. | | `3XX`, `4XX` | Any status code between 300 and 499 | Error | **If used in a task**: the task will be immediately errored, and a note will be written indicating the error message. **If used in a trigger**: no action, but the failure will be logged with the message and viewing the event in the Trigger History will provide context into the failure. | | `5XX` | Any status code in the 500s | Retry | The request will be retried, up to ten (10) times. If, after the tenth time, the response is still `5XX`, the action for the Error result will be performed. | ### Using HTTPS When attempting to use HTTP the following considerations should be made: - When possible use a fully qualified domain name for the address. For example, *https://api.mycompany.com/api/foo*. It is important that the domain on the SSL certificate bound to your web service matches the domain in the address. - The certificate used should be signed by a trusted source and not a self-signed certificate.