API testing without buying a second tool
Collections, environments and schema assertions in the same workspace as your UI tests — and they run in seconds.
API testing usually lives somewhere else: a separate client for exploring, a separate runner for CI, and a separate set of results nobody reads next to the UI ones. The seams are where coverage quietly stops.
Testver keeps API work in the same place as everything else. Build collections, point them at your environments, assert against the schema, and gate a deploy on the outcome — with no browser in the loop, so the whole suite finishes in seconds.
How API testing actually runs here
From an untouched project to a gate on your pipeline, without swapping out the tools your team already knows.
- 1
Start from a spec or a request
Import an OpenAPI spec and let the AI generate contract tests from it, or author requests directly and group them into collections.
- 2
Set environments and auth once
Environment variables and auth profiles — OAuth, API key, JWT — are defined once and reused, so the same collection runs against dev, staging and production.
- 3
Assert on structure, not just status
Schema-driven assertions catch shape changes a 200 would hide, with JSONPath and JMESPath extraction for pulling values out of a response.
- 4
Chain and script the awkward parts
Extract a token or an id from one response and feed it to the next, with pre-request and post-response JavaScript for anything the UI cannot express.
- 5
Gate the pipeline on it
Run the collection in CI as a gate. No browser means no browser start-up, so API suites are the fastest useful signal in the pipeline.
What that buys you
Seconds
No browser to start
API suites return a verdict in the time a browser would still be launching, which makes them the natural first gate on every commit.
One tool
API and UI side by side
Same workspace, same scheduling, same run history, same dashboards — instead of a separate client whose results nobody sees.
From the spec
Contract tests written for you
Point the AI at an OpenAPI document and it generates the contract coverage, rather than starting from an empty collection.
Automate API scripts in your framework, in minutes
Collections are the fast path, but plenty of teams want their API tests as code in the same repo as everything else. Ask the assistant and it writes them in your framework — REST Assured, PyTest, Playwright’s request context or whatever your project already uses — with the same authentication, environments and assertions.
- Framework-native API tests written straight into your repo, in minutes
- REST Assured, PyTest, Playwright APIRequest, RestSharp — your existing stack
- Generated from an OpenAPI spec, an existing collection, or a plain-English ask
- Run them through your own build tool and gate the pipeline on the result
“Write an API test that applies promo code SAVE20 and checks the order total and response schema.”
@Test
public void promoCodeAppliesDiscount() {
given()
.header("Authorization", bearerToken())
.contentType(JSON)
.body(new PromoRequest("SAVE20"))
.when()
.post("/api/cart/promo")
.then()
.statusCode(200)
.body("orderTotal", equalTo("79.20"))
.body(matchesJsonSchemaInClasspath("cart-schema.json"));
}What you get for API testing
Collections and environments
Organised requests with per-environment variables, ready to run anywhere.
Auth profiles
OAuth, API key and JWT handled as first-class configuration.
Schema-driven assertions
Validate the shape of a response, not only its status code.
JSONPath / JMESPath extraction
Pull values out of responses and chain them into later requests.
Pre/post request scripting
JavaScript hooks for signing, seeding or clean-up steps.
AI contract tests from OpenAPI
Generate coverage directly from the spec you already publish.
Framework-native API tests
Prefer code? The assistant writes REST Assured, PyTest or Playwright request tests into your repo instead.
Already using a framework?
Testver wraps it rather than replacing it. Pick yours to see exactly how it fits.
PlaywrightAlso works with REST Assured · PyTest · Postman collections · OpenAPI
Start testing API in three commands
No account required to install, nothing to configure first, and your existing project works as-is.
Install it
One global npm package. Node 18 or newer is the only prerequisite.
npm install -g @testver/testverGo to your test project
Testver runs from inside the framework project you want to test, so change into that folder first.
cd path/to/your-test-projectStart the dashboard
Opens at localhost:3700. Testver detects the framework, language and structure of the project you started it in and lists your tests — no configuration to write.
testver serveTypically under five minutes, start to first generated test.
Full installation guide — prerequisites, ports, running as a serviceAPI testing questions, answered
- Do we still need a separate API client?
- No. Authoring, environments, auth profiles, assertions and CI execution are all in Testver, alongside your UI suites and their reporting.
- Can Testver generate API tests from our OpenAPI spec?
- Yes. Point the AI at the spec and it generates contract tests, which you then review and adjust like any other generated code.
- Can we keep our API tests as code rather than collections?
- Yes. Ask the assistant and it writes framework-native API tests — REST Assured, PyTest, Playwright request context — straight into your repo, using the same auth and environments, and runs them through your own build tool.
- How fast are API runs compared with UI runs?
- Much faster — there is no browser to launch or page to render, so API collections typically finish in seconds, which makes them a good first gate in a pipeline.
Keep your framework. Add AI and a premium toolset.
Set up in minutes. Self-host on your own hardware. Describe a test in plain English and get working code in your own framework — in a fraction of the time.