> For the complete documentation index, see [llms.txt](https://docs.does.qa/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.does.qa/guides/seed-and-clean-up-with-api-steps.md).

# Seed and clean up with API steps

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](/values/value-store.md), run the UI path, then remove the data when you finish.

```mermaid
flowchart TD
  create["POST create resource"] --> store["Response in Value Store"]
  store --> ui["UI journey"]
  ui --> assert["GET or Check JSON Value"]
  assert --> delete["DELETE cleanup"]
```

## What you need

* API endpoints for create, read, and delete (or reset)
* Credentials or API keys as [Account Values](/values/creating-values.md)
* A [Value](/values/creating-values.md) for the API host, such as `$BASE_URL`

See [Test APIs in a Flow](/guides/test-apis-in-a-flow.md) for the first POST and token pattern.

## Seed before the UI

{% stepper %}
{% step %}

## Create the resource

Add [**POST**](/test-steps/integration/post.md) (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`.
   {% endstep %}

{% step %}

## Use stored fields in the UI

Open the app with [**Open**](/test-steps/starter/open.md). 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.
{% endstep %}

{% step %}

## Assert backend state (optional)

Add [**GET**](/test-steps/integration/get.md) or [**Check JSON Value**](/test-steps/check/check-json-value.md) to confirm the resource exists or matches what the UI should show.
{% endstep %}
{% endstepper %}

## Clean up after the UI

Add [**DELETE**](/test-steps/integration/delete.md) (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.

{% hint style="info" %}
**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.
{% endhint %}

## 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](/guides/use-mock-servers-with-doesqa.md) 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](/guides/test-data-in-doesqa.md)
* [Test APIs in a Flow](/guides/test-apis-in-a-flow.md)
* [Value Store](/values/value-store.md)
* [Built-in Values](/values/built-in-values.md)