Test APIs in a Flow

Call an API from a Flow, store the response as a Value, and assert JSON.

API calls belong in the same Flow as your browser steps. Use them to seed data, fetch a token, assert backend state, or clean up after a UI journey.

Use the Flow Builder for this walkthrough.

What you need

• A fully qualified API URL (or a Value that expands to one)

• Optional credentials or tokens as Values

• A Flow open in the Flow Builder

Build a login-token Flow

This example calls a login API, stores the JSON response, then asserts it. The same pattern works for any GET, POST, PUT, PATCH, or DELETE.

1

Open the app

Start with Open. Point it at your application URL so the Test Case has a browser context, even when the next steps are API calls.

2

Add the API call

Add POST from the Integration family.

1. Set URL to the login endpoint. Use $BASE_URL plus a path when the host changes per environment.

2. Set Body Content-Type to JSON.

3. Enter a JSON body that uses Values for credentials, for example username and password from Assets.

4. Set Response Storage Name to something clear, such as authResponse.

3

Expect the right status

Open advanced options on the POST step. Expected Response Status Codes defaults to 2xx. Change it when the API should return a specific code, such as 201.

Statuses in the 5xx range fail the step as errors.

4

Send auth on later calls

For APIs that need a Bearer token or API key, open Headers on the Integration step and pass JSON such as:

{
  "Authorization": "Bearer $API_TOKEN"
}

Keep $API_TOKEN (or similar) in Assets → Values, or overwrite it for a Run with a Run Recipe. Integration steps read Headers you set on the step. They do not reuse browser cookies from Open.

5

Assert the JSON response

Add Check JSON Value.

1. Set Input Item to the same name you stored, such as authResponse.

2. Choose Match Mode Contains or Equals.

3. Set the expected JSON with Custom, or compare against another Value Store item.

Use Check JSON Schema when you want a schema assert, or Check Value Store for a single stored field.

6

Continue with UI or more APIs

Add further Integration steps that reuse $BASE_URL and Headers, or continue with Action and Check steps on the page. The stored response stays available for the rest of the Test Case under the Response Storage Name.

When the response is JSON, reference nested fields in later steps with dot notation, for example $authResponse.token in a URL or text field. See Test data in DoesQA.

Pro tip: Store API hosts and secrets as Assets Values or Recipe overwrites. Keep response storage names specific (authResponse, order) so later Checks stay readable.

A finished login-token path looks like this:

Example API login-token Flow

Choose GET, POST, PUT, PATCH, or DELETE

Test Step	Typical use
GET	Read a resource
POST	Create a resource or submit a form-style API body
PUT	Replace a resource
PATCH	Update part of a resource
DELETE	Remove a resource

Switch Method on an Integration API step to change between these without rebuilding the rest of the step.

What gets stored

Response Object	Stored under the Response Storage Name
Body (default)	Response body
Headers	Response headers
Complete	Body and headers together

The storage name must start with a letter and use only letters, numbers, and underscores.

Environments

Use the same Flow across staging and production by keeping the host in a Value:

• Share data with Values for Assets Values and $ insertion

• Run across environments for tags and overwrites

• CI / CD to pass Value overrides from the pipeline

Browser timing is a different check

Check API Response Time measures how long a browser network request takes during the Test Case. It does not time Integration API steps. Use it when you care about page network performance, not when you are asserting an Integration response.

Related

• Test data in DoesQA

• Seed and clean up with API steps

• Integration

• POST

• Check JSON Value

• Value Store

• Share data with Values