create_load_test
Create a load test — a feature of kind load, the same object the app's Load section authors. A load test runs in one of two modes:
- Simple — replays your functional feature journeys as concurrent browser users. Pass the feature ids to replay (
featureIds); it becomes runnable (statusgenerated) as soon as it has at least one journey. - Advanced — drives protocol-level k6 traffic against URL paths (
paths). Its k6 script is built immediately, so it is runnable right away.
Omit mode and it is inferred: simple when featureIds are supplied, otherwise advanced. With no configuration fields at all, the server creates a simple-mode draft with no journeys you can refine later with update_load_test.
The REST body carries the canonical config document under config (the exact shape the app stores). The CLI and MCP tool expose the common knobs as flat arguments and assemble that document for you. The CLI/MCP wrappers use vus + rampUpSeconds + durationSeconds; REST also accepts stages: [{durationSeconds, target}] for multi-stage ramps.
Request
POST /api/v1/ops/projects/{project}/load
| Parameter | In | Type | Required | Description |
|---|---|---|---|---|
project | path | string | yes | The project's public id. |
name | body | string | no (REST) | Display name; REST defaults a blank name to New load test. Required by MCP/CLI. |
config | body | object | no | Canonical LoadConfig document (see below). Omit for the default. |
config document
| Field | Type | Applies to | Description |
|---|---|---|---|
mode | string | both | "simple" or "advanced". Omit to infer from features. |
targetUrl | string | both | Saved target URL; when set it takes precedence over run siteUrl, then the project URL. |
features | array | simple | Journeys to replay: [{ "id": 7, "name": "" }]. |
repeatsPerUser | integer | simple | How many times each concurrent user repeats the journeys (default 3). |
vus | integer | both | Concurrent browser users / protocol virtual users. Parsed values have a minimum of 1; dispatch is subject to current plan caps. |
durationSeconds | integer | advanced | Steady-load duration. |
rampUpSeconds | integer | advanced | Seconds to ramp up to vus. |
thinkTimeSeconds | number | advanced | Pause between requests. |
paths | array | advanced | URL paths to hit, e.g. ["/", "/pricing"]. |
thresholds | array | both | Pass/fail gates: [{ "metric": "http_req_duration", "condition": "p(95)<1000" }]. |
- cURL
- CLI
- MCP
curl -X POST -H "Authorization: Bearer $TESTVIBE_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"name": "Checkout under load",
"config": {
"mode": "advanced",
"paths": ["/", "/checkout"],
"vus": 50, "durationSeconds": 300, "rampUpSeconds": 30,
"thresholds": [{ "metric": "http_req_duration", "condition": "p(95)<1000" }]
}
}' \
"$TESTVIBE_SERVER/api/v1/ops/projects/$PROJECT/load"
# Simple mode — replay two functional features as 30 concurrent users
testvibe load create --name "Checkout under load" --features 7,8 --vus 30 --repeats 5
# Advanced mode — protocol k6 against paths, with a latency gate
testvibe load create --name "API soak" --mode advanced \
--paths /,/pricing --vus 50 --duration 300 --ramp 30 \
--thresholds "http_req_duration:p(95)<1000,http_req_failed:rate<0.01"
Tool create_load_test — { "name": "API soak", "mode": "advanced", "paths": ["/", "/pricing"], "vus": 50, "durationSeconds": 300, "thresholds": ["http_req_duration:p(95)<1000"] }.
Response
201 Created
{ "featureId": 51, "name": "Checkout under load", "mode": "advanced", "status": "generated" }
A simple load test with no journeys yet comes back "status": "draft" — add journeys with update_load_test before running it. Dispatch with run_load_test.
Errors
| HTTP | When |
|---|---|
400 invalid_request | Malformed request input. |
404 not_found | No such project in this workspace. |
REST also accepts configName for the simple-mode Playwright configuration and stages for advanced ramps. targetUrl stored on the load test takes precedence over a later run siteUrl; clear or update it if a different target is intended. Simple-mode threshold duration measures a whole feature replay, and request counts represent replays. Read current plan limits rather than assuming the config parser enforces a fixed user cap.