Skip to content

Functional API tests

A performance test asks “how does my API behave under load?” A Functional API test asks “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. It asserts on the response instead of measuring throughput.

From Tests → New test, select the Functional API test card, then choose how to author it:

  1. 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.

  2. Scriptless builder: build one or more HTTP requests 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.

The scriptless HTTP request builder uses the same request model as a performance test. On a functional test, the Assertions tab does the checking.

The scriptless HTTP builder supports per-request assertions without any scripting:

AssertionChecks
Status codeThe response’s HTTP status code matches an expected value
Body containsThe raw response body contains one or more literal strings
JSON pathA JSON path in the response resolves, optionally matching an expected value

Each request in the sequence has its own assertion set. A functional API test can call several endpoints in order and check each response before it moves to the next.

Functional API tests are ordinary MaxoPerf tests. Create, update, and run them from CI like any other test, with 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.