Seed and clean up with API steps

Create test data with Integration API steps before UI steps, then delete it after.

Many UI journeys need a user, order, or record that already exists in the backend. Instead of clicking through setup every time, call your API from the same Flow, store the response in the Value Store, run the UI path, then remove the data when you finish.

What you need

• API endpoints for create, read, and delete (or reset)

• Credentials or API keys as Account Values

• A Value for the API host, such as $BASE_URL

See Test APIs in a Flow for the first POST and token pattern.

Seed before the UI

1

Create the resource

Add POST (or PUT when your API uses it).

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

2. Set Body Content-Type to JSON. Use Account Values for fields the API expects.

3. Set Response Storage Name to a clear name, such as createdUser or orderResponse.

2

Use stored fields in the UI

Open the app with Open. Fill forms with built-ins or stored data:

• $testEmail for a unique inbox per Test Case

• $createdUser.email when the API returned an object and you need one field in a text input

• $createdUser.id in a URL when the app deep-links by ID

For headers on later API calls, pass JSON such as {"Authorization": "Bearer $API_TOKEN"} on the Integration step.

3

Assert backend state (optional)

Add GET or Check JSON Value to confirm the resource exists or matches what the UI should show.

Clean up after the UI

Add DELETE (or a reset endpoint your team provides) at the end of the Test Case. Use the stored ID in the URL, for example $BASE_URL/api/users/$createdUser.id.

If delete is not available, document the workaround your team accepts (dedicated test tenant, nightly reset, or a support-only cleanup script). Prefer real cleanup in the Flow when the API allows it.

Pro tip: Keep storage names specific (createdUser, authResponse). Generic names such as response make later steps harder to read when a Flow has more than one API call.

When a mock server fits better

When the API is a third-party service you cannot seed directly, point Integration steps at a mock server and store the mock base URL in Assets. The seed and cleanup pattern is the same. Stub definitions stay in Mockoon or WireMock.

Related

• Test data in DoesQA

• Test APIs in a Flow

• Value Store

• Built-in Values