From API Test to Load Test

This is the key differentiator. In every other tool, you create your API tests in one place and then rebuild them from scratch for performance testing. In Proofarc, you click one button.

The Problem

Traditional workflow:

1. Write API tests in Postman/REST Assured
2. Separately configure JMeter/k6/Gatling with the same endpoints
3. Re-configure authentication for the performance tool
4. Re-define assertions in the performance tool
5. Maintain two copies of the same test logic

Proofarc workflow:

1. Write API scenario once
2. Click "Convert to Performance Test"
3. Done. Same endpoints, same auth, same assertions. Add load phases.

How It Works

1. Start with an API Scenario

You already have a working API scenario that tests your endpoints:

Scenario: "User CRUD Lifecycle"
  Step 1: POST /api/users (create)
  Step 2: GET /api/users/{id} (read)
  Step 3: PUT /api/users/{id} (update)
  Step 4: DELETE /api/users/{id} (delete)

2. Convert to Performance Test

curl -s -X POST -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  $CSS_URL/api/scenarios/1/convert-to-performance \
  -d '{
    "name": "User API Load Test",
    "phases": [
      {"duration": 60, "arrivalRate": 5, "name": "Warm up"},
      {"duration": 120, "arrivalRate": 20, "name": "Sustained load"},
      {"duration": 60, "arrivalRate": 50, "name": "Peak load"}
    ],
    "thresholds": {
      "p95ResponseTime": 500,
      "errorRate": 1
    }
  }'

What gets carried over automatically:

• All endpoint paths and HTTP methods — including write operations (POST/PUT/PATCH/DELETE), not just reads
• Request bodies and headers
• Authentication configuration (Bearer, OAuth2, etc.), resolved per virtual user at run time
• Chained variable extraction — the id captured from POST /api/users flows into the GET/PUT/DELETE for that same user, so the whole CRUD lifecycle runs under load, not just a single read
• Per-virtual-user unique data — write bodies are auto-templated with a unique sequence, so concurrent creates don't collide on unique fields (no duplicate-key 409s under load)

What you add:

• Load phases (warmup → sustained → peak)
• Performance thresholds (P95 < 500ms, error rate < 1%)
• Virtual user count

3. Execute the Load Test

curl -s -X POST -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  $CSS_URL/api/performance-scenarios/1/run \
  -d '{"environmentId": 1, "tags": ["load-test-v1"]}'

Each virtual user authenticates independently, just like your API scenario did.

Guards against silent failure

Performance runs are protected against two failure modes that quietly waste a test run elsewhere:

• Credential guard. If the environment declares auth (a bearer login endpoint) but no credential resolves, the run refuses synchronously with CREDENTIAL_UNRESOLVED — it does not dispatch a run that 403s on every request. Add a credential to the environment (or use a public environment) and it dispatches.
• False-green floor. A run that errors 100% never reports PASS — even with no SLO declared (verdict NO_SLO_DECLARED, passed: false). Set SLO thresholds (p95, error rate) and they gate the final PASS/FAIL verdict.
• Load-param bounds. vus and duration (and each phase's arrivalRate/rampTo/maxVusers) are validated at author time: they must be between 1 and 1000 (duration up to 3600s). A vus <= 0, a negative duration (which could hang a job), or an unbounded vus is rejected with a 400 instead of dispatching a meaningless or resource-exhausting run.
• Host guard. A baseUrl of "{{myhost}}" resolves from a non-secret env property (set_env_variables) — the concrete host is substituted before Artillery runs, and non-secret properties also seed Artillery's config.variables so flow-level {{myprop}} interpolates. A property that doesn't resolve is refused rather than fired against a literal placeholder. (The {{env.myhost}} alias resolves to the same property; secrets belong in the credential vault, not properties.)

The same honest-verdict vocabulary applies to security scans. Just as perf reports NO_SLO_DECLARED when you didn't set thresholds, a security scan with no gating block reports NO_GATE_DECLARED (never PASS), and a scan that scanned nothing — 0% coverage or more errors than requests — reports ERROR, not a false-clean PASS. Release-readiness likewise holds at YELLOW ("N scan(s) still running") while a scan is in flight rather than reading "ready for release."

4. Results Feed the Readiness Score

Performance test results automatically contribute to your readiness score:

• P95 response time vs threshold
• Error rate vs threshold
• Throughput meets minimum

The same data feeds your compliance evidence — SOC 2, PCI-DSS controls about performance testing.

The Full Pipeline

API Scenario (functional correctness)
    ↓ one-click convert
Performance Test (load + stress)
    ↓ results feed
Readiness Score (0-100)
    ↓ auto-mapped
Compliance Evidence (SOC 2, PCI-DSS)

No rebuilding. No re-configuring. No manual stitching.