Functional API tests
A Functional API test answers a different question than a performance test: not “how does my API behave under load?” but “does my API behave correctly?” It runs the same kind of scenario as a performance test — one or more HTTP requests — but exactly once per execution, and its job is to assert on the response rather than measure throughput.
Create a functional API test
Section titled “Create a functional API test”From Tests → New test, select the Functional API test card, then choose how to author it:
-
Upload script — bring a scenario file for any supported executor that can express assertions — for example a Taurus YAML with
assert:blocks, an Apiritif script, or a JMeter plan with assertion elements. -
Scriptless builder — compose one or more HTTP requests directly in the console, each with its own assertions. See Scriptless test builders for the full field list.
Both paths land on the same authoring page as a performance test, with the stop mode pre-set to Iterations = 1 and locked.
What you can assert on
Section titled “What you can assert on”The scriptless HTTP builder supports per-request assertions without any scripting:
| Assertion | Checks |
|---|---|
| Status code | The response’s HTTP status code matches an expected value |
| Body contains | The raw response body contains one or more literal strings |
| JSON path | A JSON path in the response resolves, optionally matching an expected value |
Each request in the sequence carries its own assertion set — so a functional API test can walk through several endpoints in order and check each response before moving to the next.
Automating functional API tests
Section titled “Automating functional API tests”Functional API tests are ordinary MaxoPerf tests — create, update, and run them from CI the same way as any other test, using test_kind: functional-api on create. See the API reference for the full request/response shape, and open the live reference at /reference/ for the exact schema and examples.