AutoRestTest

Your API is stateful.Most API test tools aren't.

AutoRestTest reads your OpenAPI spec, works out which endpoints feed which, and generates request sequences that get deep into your API — instead of a thousand independent calls that all 400 on a missing ID.

Bring an OpenAPI 3.0 spec — or a zip of your source code. No test scripts to write.

Dependency graph
passingserver error
POST /usersGET /users/{id}POST /users/{id}/ordersGET /orders/{id}GET /reports
Run report24 endpoints
87%coverage1 server error
POST/users201
GET/users/{id}200
POST/users/{id}/orders200
GET/orders/{id}500

GET /orders/{id} returned 500 when called with an order created moments earlier — the handler assumes a shipping address that POST /orders doesn't require.

Why endpoint-at-a-time testing stalls

Real APIs have order and state. Three things break testing that ignores them.

A random ID is always a 404

GET /orders/{id} never returns 200 until something created an order first. Tools that treat endpoints independently plateau at shallow coverage, and everything behind a create-then-read wall goes untested.

Hand-written sequences rot

You can wire the fixtures up yourself, but every new endpoint means working out again which call has to come first — and the wiring breaks the next time the schema moves.

Schema-valid isn't semantically valid

A body can satisfy the schema and still be rejected when email is "string" and currency is "aaa". Coverage stalls out on 400s that were never bugs in the first place.

How it works

1

Point it at your API

Upload an OpenAPI 3.0 spec, or a zip of your source and let AutoRestTest derive one. Set a target URL, a time budget, and any auth headers.

2

It maps the dependencies

Every operation is linked to the ones whose responses can fill its parameters — a semantic dependency graph of your API, built from the spec.

3

Agents learn what works

Q-learning agents explore that graph while an LLM generates realistic values, learning which sequences and parameters actually get past your validation.

4

You get a report, not a log dump

Coverage, pass rate, and status codes per operation — with every server error called out and explained in plain language.

What you get back

Coverage that means something

Covered vs. total endpoints, pass rate across every generated test case, and a status-code breakdown per operation — not one number for the whole API.

Server errors, isolated

5xx responses are flagged separately from 4xx. A 400 is usually the test's fault. A 500 is usually yours, and those are the ones worth your morning.

Failures explained in English

Every failing endpoint gets a written explanation of what actually went wrong, generated from its real responses — not a stack trace to decode.

The dependency graph, interactive

Explore the graph in the app, with what the agents learned during the run layered over it, so you can see which paths paid off and which were dead ends.

Runs you control

Set a time budget, dial fault-injection up or down, pass custom auth headers, and exclude any endpoint you don't want called.

Built for a team

Projects with roles and invitations, so specs, runs, and reports live somewhere your whole team can read them.

Stop writing test sequences by hand.

Upload a spec and get a coverage report on your API this afternoon.