Using the HTTP Request Native Action

the http request native action in swimlane turbine allows orchestrators to interact with apis, whether or not a pre existing connector for the service exists this action facilitates sending and receiving data to/from specific api endpoints, making it a vital tool for creating comprehensive playbooks with custom outputs and enhanced performance overview the http request native action enables playbooks to make direct api calls, allowing for interaction with external services and systems this functionality is crucial for extending automation capabilities beyond the built in connectors available in swimlane turbine key benefits flexibility supports multiple http methods (get, post, put, etc ) to handle various api interactions customizable allows for detailed configuration of authentication, parameters, headers, and body content to suit specific api requirements integration easily integrates with third party services, enhancing workflow automation error handling built in options like retries and timeouts improve reliability and control over api interactions performance streamlines the automation of tasks that require external data retrieval or updates, improving operational efficiency adding the http request action to configure an http request, drag and drop the http request action from the add panel, then click configure follow the steps below to complete the configuration request method select the desired request method from the drop down get is the default request method get retrieves data, while post, put, and patch modify or add data available request methods method information get retrieve data post add, retrieve, or modify data put add or replace data patch partially update existing data delete delete existing data options request information about available actions on the target resource head retrieve response headers trace perform a message loopback test authentication tab on the authentication tab, you can select the appropriate authentication type for your api request the available types are type information no auth no authentication required api key requires key, value, and location bearer token requires a security token basic auth requires a username and password oauth 2 0 requirements depend on the oauth flow parameters tab to add query parameters to your http request, go to the parameters tab and click add parameter enter key value pairs for each parameter headers tab on the headers tab, you can view auto generated headers that will be included with your request at run time you can also add custom headers, such as content type , to meet specific api requirements body tab the body tab allows you to define the data sent in the request body available options include none , json , x www form url encoded , attachment , and form data the default option is none when using the attachment body type, only the first file in an array of files will be sent to specify a particular file, use an expression like $inputs files to scan\[0] use expressions to reference individual files if your playbook property includes an array of files settings tab in the settings tab, you can configure a proxy and enable or disable ssl/tls certificate verification to configure a proxy, select create new asset or choose an existing proxy asset from the list to disable ssl/tls certificate verification, toggle off the enable ssl certificate verification option outputs tab the outputs tab allows you to promote action outputs for use elsewhere in the playbook you can also mark data as sensitive if required by clicking the ellipsis icon and mark sensitive promoted outputs appear in the promoted playbook outputs section to remove a promoted output, click the remove button next to the promoted output retry and repeat mechanism the retry and repeat options allow for greater control over http requests, ensuring reliability and efficiency in automation workflows retry configure retry criteria to handle temporary failures you can specify the number of retries and the delay between retries example set up retries with exponential backoff for api calls that may occasionally fail due to network issues repeat use the repeat option to send the same request multiple times with different parameters or intervals handling http response codes http response codes indicate the status of the request it's crucial to handle these codes correctly to build resilient playbooks common response codes 200 ok request was successful 400 bad request client side error; check the request syntax 401 unauthorized authentication error; verify credentials 404 not found resource not found; check the url 500 internal server error server side error; consider retrying or alerting example handling 404 errors use conditional logic to check the response code and take appropriate actions, such as logging the error or retrying the request advanced use cases example 1 sending data with authentication scenario send a json payload to an api endpoint with bearer token authentication select the post method in the authentication tab, choose bearer token and provide the token configure the body tab with json and define the payload example 2 handling query parameters scenario retrieve specific data from an api by passing query parameters select the get method add key value pairs in the parameters tab example 3 handling paginated responses scenario many apis paginate large datasets here's how you can handle this scenario send the initial request and store the response check for a pagination token or next url in the response repeat the request using the next url or token until all pages are retrieved security considerations when interacting with apis, it's crucial to follow best practices to ensure security validate ssl certificates always enable ssl certificate verification to protect against man in the middle attacks secure credentials use environment variables or secure vaults to manage sensitive information like api keys or tokens limit data exposure only promote outputs that are necessary, and mark sensitive data appropriately to prevent unintentional exposure troubleshooting request fails with 401 unauthorized ensure the correct authentication method and credentials are provided unexpected response format verify the api documentation and ensure your headers and body match the expected format timeout issues increase the timeout settings or check network stability best practices use secure authentication always prefer secure methods like oauth 2 0 or bearer tokens over basic auth test api endpoints validate api endpoints and configurations in a testing environment before deploying them in production use descriptive variable names clearly label your parameters and headers for easy identification and debugging use cases for examples of how to use the http request action, see the http request use case