HTTP Monitor

In this section, we will guide you on how to use the HTTP Monitor block.

Use Cases

The HTTP Monitor block is used to listen for network requests (HTTP requests) sent by the web page, capturing request or response data that matches specified rules for use in subsequent flows.

By setting the request method and matching rules, HTTP Monitor can accurately intercept target APIs and extract request bodies or response results.

example

How Does It Work?

When a webpage loads or operates, the browser constantly sends various network requests (such as fetching API data, submitting forms, refreshing tokens, etc.).
The HTTP Monitor block silently listens to these requests in the background, and when it detects a request that matches your settings (like a specific URL or method), it captures the corresponding request or response data.

The general workflow is as follows:

  1. Webpage sends a request: The webpage sends an HTTP request to the server (e.g., GET or POST requests).
  2. Block listens for requests: HTTP Monitor checks each request in real-time based on your configured Method and Pattern.
  3. Capture on match: If the request URL and Method match your settings, it captures either the request content (Request) or the response content (Response).
  4. Save to variable: The captured data is saved into the variable you specified, allowing downstream modules to use it (e.g., extracting fields, making decisions, filling forms, sending notifications, etc.).

With this method, Tapicker can retrieve API data invisibly without modifying the page itself or sending additional requests, enabling highly flexible automation workflows.

How to Find APIs?

You can press F12 on the page to open the Developer Tools, then switch to the Network panel. Follow the steps shown below to locate the API you want to monitor.

find-api

Method

The HTTP request method to monitor, including: GET, POST, PUT, PATCH, DELETE, etc. The default method is GET.

Pattern

Required. The URL matching rule for requests. Wildcards * are supported, for example:

https://www.example.com/api/products/*

For more pattern rules, please refer to: URLPattern.

Request

You can extract the request data from the API. The default parsing method is Auto, meaning it automatically parses data based on the Content-Type in the request headers. This works correctly in most cases, but if necessary, you can manually specify a parsing method.

When you need to access the request data, you must assign it to a variable, such as Req. Its structure looks like this:

{
  "url": "https://www.example.com/api/products/123",
  "method": "GET",
  "query": {
    "foo": "bar",
    "hello": "world"
  },
  "headers": {
    "content-type": "application/json"
  },
  "body": "data..."
}

To access the request data, you can use the following expression:

{{@vars.Req.body}} // "data..."

Response

You can also extract the API's response data. It is automatically parsed based on the Content-Type in the response headers, and you can manually specify a parsing method if needed.

When you need to access the response data, you must assign it to a variable, such as Res. Its structure looks like this:

{
  "url": "https://www.example.com/api/products/123",
  "method": "GET",
  "status": 200,
  "statusText": "OK",
  "headers": {
    "content-type": "application/json"
  },
  "body": "data..."
}

To access the response data, you can use the following expression:

{{@vars.Res.body}} // "data..."

More Settings

In More Settings, you can specify the execution context, timeout duration, and whether to wait for the monitor to complete.

more-settings

Subframe

If needed, you can specify the execution context for the monitor by matching the iframe URL. By default, it runs in the Main Frame. In most cases, you don't need to change this setting.

Wait For Completion

Wait for the monitor to finish executing — this is the default behavior. If you disable this option, you may need to use the Wait Until block to ensure the monitor has finished before accessing its variables.

Notes

  • If there are many network requests on the page, it is recommended to set the Pattern precisely to avoid capturing irrelevant requests.
  • If the API URL contains dynamic parameters (like random IDs or timestamps), you can use the * wildcard for fuzzy matching.
  • On complex pages, it is recommended to combine with condition judgment blocks to ensure the captured data meets expectations.

On This Page