Block reference / General

HTTP request

Sends an HTTP request to a URL and can store the response.

In both appsWarpX BrowserWarpX Phone

Use HTTP request to send data a run has collected to your own server, or to fetch data from an API for later blocks. WarpX Browser sends the request through the proxy of the profile the run is on, so it leaves from the same address as the browser. It has a second output that the run takes when the request fails.

The HTTP request block's settings, filled in as in the example below.

Settings

Description

A note shown under the block's name on the canvas. It has no effect on the run.

ExampleSend the new account to our server
Request method

GET, POST, PUT, PATCH, DELETE or HEAD. GET and HEAD send no body.

ExamplePOST
Request URL

The address to send to. It must start with http. References such as {{variables.orderId}} are filled in first.

Examplehttps://hooks.example.com/orders
Content type

How the body is sent: text/plain, application/json, multipart/form-data or application/x-www-form-urlencoded. The block sets the matching Content-Type header itself.

Exampleapplication/json
Timeout (0 to disable)

How long to wait for an answer, in milliseconds. A request that runs out of time counts as failed.

Example10000
Headers

One row per header: a name and a value. Click Add header for another row. References in the value are filled in, and a row with an empty name or value is not sent.

ExampleAuthorization | Bearer {{variables.apiToken}}
Bodywhen Request method is not GET or HEAD

Click the body to edit it. For JSON and form content, write JSON. For multipart/form-data, write a list of [name, value] pairs. References are filled in before sending.

Example{"email": "{{table.email}}"}
Response type

How to read the answer: JSON, Text or Base64. It only matters when you store the response.

ExampleJSON
Data pathwhen Response type is JSON

The part of a JSON answer to keep, for example data.id. Leave it empty to keep the whole answer. Start it with $response to reach the status and URL too, for example $response.status.

Exampledata.id
Assign to variable

Stores the response in a variable.

ExampleChecked
Variable namewhen Assign to variable is on

The variable to store it in. Read it later as {{variables.leadId}}.

ExampleleadId
Insert to tablewhen the workflow has table columns

Writes the response to a table column. It only appears when the workflow's table has columns.

ExampleUnchecked
Select columnwhen Insert to table is on

The column to write to. Choose [Assign columns] when the response is a list of objects and each key should go to the column of the same name.

Example[Assign columns]
Delay time (ms)

A pause after the request, before the next block. Write a fixed number such as 1000, or a range such as 1000,3000 for a random pause each time.

Example0

Every block also has the shared block settings — a description, Disable block and what to do on an error. Fields that take text accept data from earlier blocks.

What it hands on

When Assign to variable or Insert to table is on, the response (or the part at Data path) goes to that variable or column. The block leaves by its main output on a 2xx answer. It leaves by its fallback output when the server answers with an error status or does not answer at all.

Example: Send a new account's email to your server

  1. Start
  2. Open URL
  3. Get text
  4. HTTP request
  5. Notification
Where HTTP request sits in the example workflow.
  1. In the Start block, add an Input (string) parameter named apiToken.
  2. Use a Get text block to read the account's email into a table column named email.
  3. Add an HTTP request block. Set Request method to POST, Request URL to https://hooks.example.com/orders and Content type to application/json.
  4. On Headers, click Add header and enter Authorization with the value Bearer {{variables.apiToken}}.
  5. On Body, enter {"email": "{{table.email}}"}.
  6. On Response, keep JSON, set Data path to data.id, tick Assign to variable and name it leadId.
  7. Connect the fallback output to a Notification block so you hear about a failed request.

On WarpX Phone

  • On WarpX Phone there is no profile proxy. The request goes out directly from this computer's own connection, not through the proxy of the phone's identity, and the server sees this computer's address.
  • With no page to try again from, a request that gets no answer takes the fallback output, or fails, at once.
  • A multipart/form-data row that names a web address cannot be read on a phone, because that file is fetched by a profile's browser. Name a file on this computer instead.

Good to know

  • The request is sent by WarpX Browser through the profile's proxy, not by the page, so the server does not need to allow requests from the page's site. If the request gets no answer at all, and did not simply time out, the app tries once more from the profile's page, where that restriction does apply.
  • A request with multipart/form-data is sent directly by WarpX Browser's automation, not through the profile's proxy, and the server must allow cross-site requests.
  • A Content-Type header you add yourself is replaced by the one Content type sets.
  • {{table.email}} reads the first row of the table. Inside a Loop data loop, use the loop's reference, such as {{loopData.orders.email}}, to send each row.
  • With Response type set to JSON, an answer that is not JSON fails the block with Expected JSON but the response was .... A Data path that matches nothing also fails it, and names the path.
  • Taking the fallback output is logged as an error on this block, even though the run carries on.

See also

  • Loop data — Run the blocks after it once for each row, number, list item or element.
  • Insert data — Set variables and add values to the workflow's table, several at once.
  • Wait connections — Holds branches that run side by side until they have all arrived.