Network requests

There are two ways to make network requests as part of a test:

Simple GET requests inline as a test step
cURL requests that run before the test starts (pre-requests)

Inline GET requests

You can make a GET request directly in a test step and use the response data in subsequent steps.

Example: retrieving an OTP code

Assuming there is an endpoint to retrieve an OTP code:

https://customer-api.com/fetch-otp?customer=...&apiKey=...

With a response like:

{
  "otp_code": "123456"
}

You can use the following test steps:

1. Perform a network request to https://customer-api.com/fetch-otp?customer={{env.username}}&apiKey={{env.api-token}} with the json selector 'otp_code'
2. Enter the remembered otp_code in the password field

Step 1 makes the request and remembers the otp_code from the response. Step 2 uses the extracted value by referencing it as “remembered”. You can use environment variables (e.g. {{env.username}}) as part of the URL. For more complex requests like POST or DELETE with payloads, use pre-requests instead.

Pre-requests (cURL)

Pre-requests let you execute cURL commands before the test starts. This is useful for setup tasks like cleaning data, creating test accounts, or fetching credentials.

Step 1: Define the cURL commands

Navigate to the Settings tab within your test. In the Pre-requests section, define one or more cURL commands that will be executed sequentially before the test runs. Examples:

# Delete order history before the test
curl -X DELETE "https://api.example.com/users/123/order-history" \
     -H "Authorization: Bearer {{env.apitoken}}"

# Create a test user
curl -X POST "https://api.example.com/users/create" \
     -H "Content-Type: application/json" \
     -d '{"userType": "premium"}'

Step 2: Define values to remember

If a pre-request returns values you want to use in the test, name them in the pre-request settings. A name is a JSON key, a path into the response, or a path that indexes an array along the way. Given this response:

{
  "user": {
    "username": "generated_user_123",
    "password": "123456"
  },
  "ads": [{ "id": "a-1" }, { "id": "a-2" }]
}

user.username, user.password and ads.0.id are all usable names. Nested objects do not need flattening. The value is then referenced by the last segment of its name, so user.username is remembered as username and ads.0.id as id. Two values that end in the same key would collide, so give one of them a name of its own upstream if your response has, say, both a user.id and an ad.id.

Platform tests name a remembered value by its whole path instead, as MB_PRE_USER_USERNAME, which lets one test carry both a user.id and an ad.id. See Setup and cleanup calls.

Step 3: Use remembered values in the test

Reference the remembered values in your test steps using the “remembered” keyword:

Tap on the username input field
Type the remembered username
Tap on the password input field
Type the remembered password

Requests to internal services

Both inline requests and pre-requests are made from MobileBoost, so the endpoint has to be reachable from the internet. If the API you need lives on a staging environment that is not public, open a tunnel from your network and name it in the run. See Test against internal environments.

Builds

Test cases

No-code test editor

Test results

Inline GET requests

Example: retrieving an OTP code

Pre-requests (cURL)

Step 1: Define the cURL commands

Step 2: Define values to remember

Step 3: Use remembered values in the test

Requests to internal services

​Inline GET requests

​Example: retrieving an OTP code

​Pre-requests (cURL)

​Step 1: Define the cURL commands

​Step 2: Define values to remember

​Step 3: Use remembered values in the test

​Requests to internal services

Inline GET requests

Example: retrieving an OTP code

Pre-requests (cURL)

Step 1: Define the cURL commands

Step 2: Define values to remember

Step 3: Use remembered values in the test

Requests to internal services