Overview

Test configuration keeps tests portable across environments: instead of hardcoding base URLs, headers, and inputs into every test, you define them once on the project and inject them at run time. Environments, project-level headers, and run data all live in the project editor; a separate Test Configurations modal captures reusable per-endpoint request shapes. Use these together so the same test runs cleanly against Dev, Staging, and Production.

Before you begin

You need a project you can edit.
Decide which environments you'll target (for example Development, Staging, QA, Production) and where run data comes from.
Nav path: open the project editor. The tabs used here are Environment Settings and Data for Running Tests. The Test Configurations modal is opened from the test-configuration control in the app toolbar.

Step 1 — Set base URLs per environment

In the project editor, click the Environment Settings tab.
Under Base URLs by Environment, each configured environment has a row with a radio button (the default environment), the environment name, and a base-URL field (placeholder like e.g. https://api-development.example.com). Enter the base URL for each environment you use.
Select the radio button on the environment you want as the default—the one tests use unless overridden at run time. Archived environments can't be set as default.
To add another environment, use the Add Environment row: enter a name and base URL, then save. Existing environments can be archived (hidden from dropdowns, history preserved) or deleted with the row buttons; you can't archive or delete the current default.

Step 2 — Add project-level headers

Still on Environment Settings, scroll to Project-Level Headers.
Click Add Header to add a row, then fill the header name and value (for example an auth, tenant, or correlation-ID header). Remove a row with its trash button.
These headers are applied to tests in the project so you don't repeat them per test. Store secrets in your secret manager rather than pasting raw credentials.

Step 3 — Save the configuration

Click Save Settings at the bottom of the tab. Blank header rows (missing name or value) are dropped on save. If a save fails, a dismissible red error banner appears at the top of the tab.

Step 4 — Attach data for data-driven runs

Open the Data for Running Tests tab to make tests run once per row of data instead of a single hardcoded input. Studio has two complementary systems:

Datasets and the Data-Driven testing panel — internal tables, saved datasets, or generated data, bound with {{row.COLUMN}} tokens. See Data-driven testing.
Data Sources — reusable connections to CSV / Excel / Database / JSON / API, bound with [[variable]] tokens. See Data sources.

Step 5 — Create a reusable endpoint configuration (Test Configurations)

The Test Configurations modal stores reusable per-endpoint request shapes that generation and tests can build on.

Open the Test Configurations modal. It lists existing configurations as cards (method chip, name, path, parameter count, and any auth / rate-limit chips).
Click Add Configuration to create one, or the edit (pencil) icon on a card to change one. The form opens with these sections:

Field	What it does
Name	Label for the configuration (required).
Method	GET, POST, PUT, PATCH, or DELETE.
Path	The endpoint path (required).
Description	Optional free-text notes.
Parameters	Add rows with Name, Type (String / Number / Boolean / Array / Object), and Description via Add Parameter; remove with the trash icon.
Request Body (JSON)	A JSON object representing the request-body schema.
Authentication	Tick Requires Authentication to reveal Type (none, basic, bearer, apiKey, oauth2) and an Auth Config (JSON) object.
Rate Limiting	Tick Enable Rate Limiting to set Requests and Period (seconds).
Custom Test Suggestions (optional)	Method-specific suggestion text you can override or extend; leave blank to use the defaults shown above the field.

Click Save. Invalid JSON in Request Body or Auth Config is rejected with an alert ("Invalid JSON in Request Body" / "Invalid JSON in Auth Config"). A confirmation snackbar reports success; delete a configuration with the trash icon on its card.

Troubleshooting

"Invalid JSON in Request Body" / "Invalid JSON in Auth Config" — fix the JSON syntax in the Test Configurations form before saving.
Can't archive or delete an environment — it's the current default; set another environment as default first.
Headers didn't save — rows missing a name or value are dropped on save; fill both fields.
Test hit the wrong host — confirm the base URL for the selected environment and that the intended environment is set as default on Environment Settings.

Best practices

Keep one base URL per environment and name environments clearly (Dev, Staging, Prod).
Rotate tokens and secrets; avoid committing sensitive values or pasting them into config fields.
Use unique IDs per run to prevent collisions, and update configuration when endpoints, environments, or auth mechanisms change.

Test Configuration