Web API Data Stream Parameters

The WebAPI plugin provides a single configurable data stream: HTTP Request. Use the parameters to configure the request to send to an API endpoint.

Each configurable data stream exposes a set of parameters that lets you filter the data you retrieve. The following information describes the available configurable data streams and their parameters in detail.

Configuration tabs

To configure this data stream, you must work your way through each of the following tabs configuring each one as needed.

Basics

Use the Basics tab to configure the type pf request and the endpoint that the request is sent to.

Parameter
Description
Type
Select the type of request to send. This determines how the request is structured and how the remote server processes it. The type you should select depends on what the API you are querying is expecting. Choose from:
  • GET: Select to simply fetch data from an endpoint.
  • POST: Select to send data (such as JSON or form data) to the endpoint.
Base URL
This value is read-only and is determined by entering the Base URL when configuring the data source. It represents the root address of the target API or service. The final request URL is built by combining this base URL with the specified Path.
Path
Enter the specific resource or route (for example, /v1/data or /users/list) that identifies where the request should be sent. This field allows flexibility to target different endpoints under the same base URL.

Body

Use the Body tab to the content sent in the body of a POST request. This tab only displays when POST is selected on the Basics tab.

  • Body: Enter the data payload to include in the request body. The format typically depends on the API requirements and the Content-Type header.

Parameters

Use the Parameters tab to add key:value pairs to include in the request’s query string. Query parameters are appended to the end of the URL to pass data or filter results (for example, ?status=active&limit=100).

Parameter
Description
Add new query parameter /
Add another query parameter
Click to add a set of key:value parameter fields.
MyParam
Enter the name (key) of the parameter. For example, status.
123
Enter the value of the parameter. For example, 100. You can click the Encrypt
/ Decrypt
icon to toggle the encryption of the parameter value.

Headers

Use the Headers tab to add custom HTTP headers to include in the request. Headers provide additional metadata or configuration details for the HTTP request (for example, authentication tokens, content type, or custom app identifiers).

Parameter
Description
Add new header /
Add header
Click to add a set of key:value header fields.
MyHeader
Enter the name (key) of the header. For example, Content-Type.
123
Enter the value of the header. For example, application/json.

Paging

Use the Paging tab to optionally configure pagination for the request. Supported paging modes include Next URL, Token and Offset.

Parameter
Description
Mode
Select how paging is handled. The correct option to choose depends on the API you are sending the request to. Choose from:
  • None: Paging is disabled.
  • Next URL: Used when a value in the response specifies a URL for the next page of data.
  • Token: Used when a value in the response specifies a token for the next page of data.
  • Offset: Uses a starting value to step through results, one page at a time.
Page size
Select how to configure the requested page size. This size can be varied to optimize performance.

Too many small pages being fetched may cause the tile to time out before all data is received. A page that's too large may cause payload size limits to be exceeded within the SquaredUp app.

Choose from:
  • None:
    The API’s built-in default page size is used. No page size value is explicitly sent with the request.
  • Body (POST requests only):
    The page size is included in the request body. Use this option when the API expects pagination settings as part of a body.
  • Header:
    The page size is sent in an HTTP header. This is useful when pagination is configured via custom or standard headers.
  • Query parameter:
    The page size is passed as a query string parameter in the request URL (for example, ?pageSize=50).
Path to page size
Specify the exact location or name used by the API to read the page size value. Then specify number of records to request per page in the right-hand field. This must be a positive integer and should respect any limits enforced by the API.

Next URL

These fields display when Next URL is selected as the paging mode.

Parameter
Description
Next URL
Select where in the response the URL for the next page of results is provided. This URL is used to retrieve the subsequent page without manually constructing pagination parameters.
  • Body: The next page URL is included in the response body. Use this option when the API returns a field containing the full URL for the next page (for example, next, links.next, or pagination.nextUrl).
  • Header: The next page URL is provided in an HTTP response header. This is commonly used for pagination metadata returned outside the response body.
  • Web link: The next page URL is included in a response header using standard web link relations rel="<value>" (for example, next). Use this option when the API follows HTTP link-based pagination conventions.
After choosing where the next page URL is located, enter the exact path to find the next URL in the right-hand field.

Token

These fields display when Token is selected as the paging mode.

Parameter
Description
Token in response
Select where in the response the token for fetching the next page can be found. Choose from:
  • Header:
    The pagination token is returned in an HTTP response header. Use this option when the API exposes the token as part of the response metadata.
  • Body:
    The pagination token is included in the response body. This is common when the API returns a token field such as nextToken, cursor, or continuationToken.
Then, enter the exact path to the incoming token in the right-hand field.
Token in request
Select where the pagination token should be inserted in the request to retrieve the next page of results. Choose from:
  • Header:
    The pagination token is sent in an HTTP request header. This is commonly used when the API requires pagination or continuation tokens to be passed in headers.
  • Query parameter:
    The pagination token is sent as a query string parameter in the request URL (for example, ?pageToken=abc123). Use this option when the API expects the token as part of the URL.
  • Body (POST requests only):
    The token is sent in the request body. Use this option when the API expects the token as part of a body.
Then, enter the exact path to send the token in the right-hand field.

Offset

These fields display when Offset is selected as the paging mode.

Parameter
Description
Row count
Select where in the response the total number of rows returned for the current request can be determined. Choose where the row count is located:
  • Body:
    The row count is provided as a value in the response body. Use this option when the API explicitly returns a field containing the number of rows in the current page.
  • Body array size:
    The row count is determined by counting the number of items in an array in the response body. Use this option when the API does not return a separate count field and the page size must be inferred from the array length.
  • Header:
    The row count is provided in an HTTP response header. This is commonly used when pagination metadata is returned outside the response body.
After selecting the location, enter the exact path to the field or array used to determine the row count in the right-hand field.
Offset by
Select how the offset value is calculated for subsequent requests. Choose from:
  • Page:
    The offset represents the page number. Each subsequent request increments the page index.
  • Row:
    The offset represents the number of rows to skip. Each subsequent request increases the offset by the number of rows returned.
Page / Row
Select where the page or row offset value is sent in the request. Choose from:
  • Query parameter:
    The offset is sent as a query string parameter in the request URL (for example, ?offset=20 or ?page=3).
  • Header:
    The offset is sent in an HTTP request header. Use this option when the API expects pagination offsets in headers.
  • Body (POST requests only):
    The offset is sent in the request body. Use this option when the API expects the offset as part of a body.
After selecting the location, enter the exact path used by the API to receive the offset value in the right-hand field.
Starting offset
Enter the initial offset value to use for the first request. This value determines where pagination begins and will typically be 1 or 0.

Response

Use the Response tab to display the response returned from the configured HTTP request and to optionally configure the data path.

Parameter
Description
Response preview
After clicking the Send button, this field displays the raw JSON response or any error message generated by the request. Use this preview to verify that the endpoint is reachable and that the returned data matches your expectations.
Select data
Determine how to traverse to the data from the response object. Choose from:
  • Path: Enter the exact JSON path to select the portion of the response you want to use. For example,
    data.items
    or
    results[0].value
  • Use a custom JavaScript snippet to transform the response. For example,
    result = JSON.parse(data).map(o => o.value);
    This is useful for integrating with any API where the data you need is deeply nested in the response, and can also be used to shape the returned data.

Request examples

The following examples aim to guide how to populate each of the Configuration tabs to build your HTTP requests.

The following examples use dummy data and are for purely demonstrative purposes. The exact format of expected parameters / headers depends entirely on the API you are querying and you should refer to that API's documentation.

Create a GET request to retrieve user data

Fetch a list of users from a public API with optional filters.

  1. On the Basics tab, configure the following:
    • Type: GET
    • URL: https://api.example.com (read-only)
    • Path: /v1/users
  2. On the Parameters tab, configure the following, this defines the following for the resulting request URL https://api.example.com/v1/users?status=active&limit=50:
    Name
    Value
    status
    active
    limit
    50
  3. On the Headers tab, configure the following:
    Name
    Value
    Accept
    application/json
    Authorization
    Bearer {{api_token}}
  4. On the Response tab, configure the following:
    • Response Preview: Click Send to displays JSON such as
      {
  "data": [
    { "id": 1, "name": "Alice" },
    { "id": 2, "name": "Bob" }
  ],
  "total": 2
}
    • Select data:
      • Path
      • data
    • Expand Inner Objects: Toggle on to view full user details

Create a POST request to query analytics data

  1. On the Basics tab, configure the following:
    • Type: POST
    • URL: https://api.example.com (read-only)
    • Path: /v1/sales/query
  2. On the Body tab, configure the following:
    • Body: This request asks the API to return aggregated sales metrics for a specific date range and region
      {
  "startDate": "2025-11-01",
  "endDate": "2025-11-07",
  "region": "North America",
  "metrics": ["totalSales", "averageOrderValue", "transactions"]
}
  3. On the Parameters tab, leave the fields empty, as query parameters are included in the request body for this API.
  4. On the Headers tab, configure the following:
    Name
    Value
    Content-Type
    application/json
    Authorization
    Bearer {{api_token}}
    Accept
    application/json
  5. On the Response tab, configure the following:
    • Response Preview: Click Send to display JSON such as
      {
  "status": "success",
  "data": {
    "summary": {
      "totalSales": 157340.25,
      "averageOrderValue": 78.12,
      "transactions": 2014
    },
    "dailyBreakdown": [
      { "date": "2025-11-01", "totalSales": 22000.50 },
      { "date": "2025-11-02", "totalSales": 24350.00 },
      { "date": "2025-11-03", "totalSales": 18000.75 }
    ]
  }
}
    • Select data:
      • Path
      • data.dailyBreakdown
    • Expand inner objects: Toggle on to view nested objects like summary and dailyBreakdown

Script examples

The following gives examples of how you can integrate SquaredUp with even more APIs by shaping response data exactly how you need it before visualizing.

Normalizing an inconsistent API response

This script drills into nested objects, extracts only the useful fields, and outputs a clean array of simple objects. Ideal for visualizations that cannot consume deeply nested structures.

Response JSON:

{
  "meta": { "timestamp": "2025-01-01" },
  "response": {
    "records": [
      {
        "attributes": { "id": 1, "info": { "value": 10 } },
        "status": "ok"
      },
      {
        "attributes": { "id": 2, "info": { "value": 20 } },
        "status": "ok"
      }
    ]
  }
}

Script:

result = data.response.records.map(r => ({
  id: r.attributes.id,
  value: r.attributes.info.value,
  status: r.status
}));

Output JSON:

[
  { "id": 1, "value": 10, "status": "ok" },
  { "id": 2, "value": 20, "status": "ok" }
]

Reshaping API output from multiple nested collections

This example flattens a hierarchical projects > tasks structure into a single list, allowing tables or charts to display all tasks with their related project names.

Response JSON:

{
  "projects": [
    {
      "name": "Alpha",
      "tasks": [
        { "taskId": 1, "hours": 5 },
        { "taskId": 2, "hours": 3 }
      ]
    },
    {
      "name": "Beta",
      "tasks": [
        { "taskId": 3, "hours": 4 }
      ]
    }
  ]
}

Script:

result = data.projects.flatMap(project =>
  project.tasks.map(t => ({
    project: project.name,
    taskId: t.taskId,
    hours: t.hours
  }))
);

Output JSON:

[
  { "project": "Alpha", "taskId": 1, "hours": 5 },
  { "project": "Alpha", "taskId": 2, "hours": 3 },
  { "project": "Beta",  "taskId": 3, "hours": 4 }
]

Parsing CSV returned inside JSON

This script converts a CSV string into an array of objects (one per row) so the data can be visualized like any other structured dataset.

Response JSON:

{
  "csv": "time,value\n2024-01-01,10\n2024-01-02,15"
}

Script:

const lines = data.csv.trim().split("\n");
const [header, ...rows] = lines;

const cols = header.split(",");

result = rows.map(line => {
  const values = line.split(",");
  return Object.fromEntries(cols.map((c, i) => [c, values[i]]));
});

Output JSON:

[
  { "time": "2024-01-01", "value": "10" },
  { "time": "2024-01-02", "value": "15" }
]

Adding totals, averages, and ratios

This script calculates new metrics like revenue and averages.

Response JSON:

{
  "sales": [
    { "region": "NA", "units": 120, "price": 5 },
    { "region": "EU", "units": 150, "price": 4 }
  ]
}

Script:

result = data.sales.map(s => ({
  region: s.region,
  revenue: s.units * s.price,
  units: s.units,
  price: s.price,
  averageRevenuePerUnit: (s.units * s.price) / s.units
}));

Output JSON:

[
  {
    "region": "NA",
    "revenue": 600,
    "units": 120,
    "price": 5,
    "averageRevenuePerUnit": 5
  },
  {
    "region": "EU",
    "revenue": 600,
    "units": 150,
    "price": 4,
    "averageRevenuePerUnit": 4
  }
]

Was this article helpful?

Have more questions or facing an issue?
Submit a ticket