Skip to main content

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/execute \
  -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.

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.