DashboardSign inStart your trial
In this guide · BuildClose guide

HTTP Request

Call a REST API from a workflow, securely pass credentials, and use the response in later steps.

Use an HTTP Request step to call a REST API when you need a service that is not available as a connected app or when a one-off request is enough.

#Set up the request

  1. Add an HTTP Request step.
  2. Choose a method: GET, POST, PUT, PATCH, or DELETE.
  3. Enter the URL. You can include values from earlier steps with the variable picker.
  4. Add any headers and, for POST, PUT, or PATCH, choose a body format and provide the body.
  5. Choose how Rills should handle the response.

The request times out after 30 seconds by default. You can set a timeout from 1 to 300 seconds.

#Authenticate securely

Choose Bearer Token, API Key, or Basic Auth when the API requires credentials. Add a connection in Integrations, then select it on the step instead of pasting a secret into a URL, header, or body.

For an API key, set the header name the service expects. Rills uses X-API-Key when you do not specify one.

#Send data

For POST, PUT, and PATCH requests, choose one of these body formats:

  • JSON for most APIs
  • Form data when the API expects URL-encoded fields
  • Plain text
  • XML

Use the variable picker to insert information from earlier steps. For JSON, Rills checks a fixed body for valid JSON before the workflow runs; a body containing variables is checked after those values are filled in.

#Use the response

Choose whether the response is JSON, text, or a file. A successful request makes these values available to later steps through Insert data from an earlier step:

  • Status for the HTTP status code
  • Status text for the status text
  • Data for the response body

For a JSON response, leave parsing on to use its fields in later steps. Add a response-body schema when you know the response shape and want more precise suggestions in the variable picker.

By default, status codes from 200 through 299 count as successful. You can define a different set of successful codes when the API needs it.

#Failures and retries

A response outside the successful status codes causes the step to fail. The run detail shows the status code and a preview of the response, so you can see what the service returned.

HTTP Request steps support the standard retry policy for temporary failures. See Runs & Versions to inspect failures and retries.

#See also