API tests are the fastest and most stable tests a team can have. They don't wait for pages to render, they don't break when a button moves, and they catch problems before the UI ever sees them. Yet on many teams they're the most neglected part of the suite.
Usually the tooling is to blame. Requests get explored in one app, automated in a separate code framework, and contract-checked somewhere else, if they're checked at all. Every handover between those tools loses something.
In Testver, the whole job happens in one conversation. You describe what an API should do in plain English. The AI Assistant sends the requests, checks the answers, saves everything it builds, and at the end writes real test code in your own framework. This guide walks through it, from importing an API to a suite that runs on every commit. For the complete, lesson-by-lesson version, see the API Testing with AI guide in the Testver docs.
Before you start
Open the AI Assistant and choose API in the mode picker next to the message box. API mode works only with APIs, your project's files and the terminal, so no browser gets involved.
Next to the mode picker is the Manual / Auto switch. In Manual, the default, the assistant asks before anything that sends traffic or changes your project, and you click Allow or Deny. Reading saved requests or comparing spec files never asks. Switch to Auto once you trust the environment and want a long flow to run without interruptions.
Have three things ready:
The address of a test environment, such as https://qa.example.com/api. Never start with production: POST, PUT and DELETE change real data. Say "this is our QA environment" in your prompt.
Credentials for it: a token, an API key, a username and password, or OAuth2 client credentials.
Optionally, a description of the API: an OpenAPI or Swagger file or its URL, or a Postman collection.
You also need Testver running on your project and an AI connection: Testver cloud AI (the free Starter needs no card) or a local model through Ollama or LM Studio. New to Testver? Start with Meet Testver.
Step 1: Bring your API in
Ask the assistant to import whatever describes your API:
Import api/openapi.yaml as a collection called "Shop API" and tell me which endpoints it created.
Every endpoint becomes a saved request, grouped by tag, with example bodies and parameters. Testver reads OpenAPI 3 and Swagger 2 files in JSON or YAML, a spec's URL, and Postman v2.1 collections. Attach a file with the paperclip, or give its path in your project. Importing only creates the requests; nothing calls your API until you ask.
No spec at all? Record the API your app actually uses. Open the app in your browser, press F12, use the features you want to test, then save the Network tab as a HAR file and attach it:
Import the attached HAR as Shop API.
The assistant keeps only the real API calls and merges repeated calls into one request, turning ids into variables (/orders/123 becomes /orders/{{id}}). It also strips your session: tokens become {{token}} and cookies are dropped, so no secret is saved.
Then add environments, and the same requests run anywhere:
Create environments Dev, QA and Staging for Shop API with baseUrl https://dev.shop.test, https://qa.shop.test and https://staging.shop.test.
Everything is saved in your project, so it's there next time.
Step 2: Send a request and check the answer
Describe the call in words, including the method, query, headers, body and auth:
POST to /users with body {"name": "Ann", "role": "viewer"} and bearer token {{token}}, then explain the response.
You get the status, the time taken, the headers, the formatted body, and a short explanation of what came back. Basic auth, API keys and OAuth2 client credentials work the same way: say which one. The OAuth2 token is fetched, reused until it expires, and sent for you. GraphQL queries and file uploads are just another sentence.
A 200 OK only means the server answered. A test checks that it answered correctly, so ask for checks:
Call GET /users/1 and check that the status is 200, $.email contains "@", the Content-Type header contains application/json, and it answers in under 500 ms.
You can check the status, any header, a body field by JSON path, the body text and the response time. You can also check the whole body against a schema, including one from your own spec:
Validate the response of GET /orders/42 against the 200 response of GET /orders/{id} in api/openapi.yaml.
Each failure names the exact field, for example /items/0/price: must be number. Ask for checks on a saved request ("add these checks to the Get order request") and they're kept, running every time that request runs.
Step 3: Test real flows with chains
Real features take several calls in a row: sign in, create something, read it back, change it, delete it. A chain runs a folder of requests in order, passing values from one step to the next:
Build a chain "Checkout" in Shop API: log in with {{user}} and {{password}} and keep $.token; add product 12 to the cart; check out and keep the order id; then poll the order every 2 seconds until $.status is CONFIRMED. Run it against QA.
The assistant adds the extract rules for you ("keep $.token as {{token}}"), and later steps use the values. A step passes only when its status is OK, every check passes, and every extract found its value. A 200 with the wrong body is a failure. The chain stops at the first failing step and marks the rest as skipped, so you never chase errors caused by a value that was never extracted.
The result is a card with one row per step. Open a step to see what was sent, what came back, and exactly why it failed. Notice the poll in the prompt above: for services that finish work in the background, a step retries until its checks pass, which is far more reliable than a fixed sleep.
Step 4: Cover more cases with data
One request with one set of inputs tests one case. Save a CSV or JSON file in your project and run the same request, or a whole chain, once per row:
email,password,expected_status
ann@test.io,Str0ng!pass,201
not-an-email,Str0ng!pass,400
bob@test.io,short,400Run the Sign up request of Accounts API once per row of data/signup.csv.
You get one result line per row. The optional expected_status column lets a row expect a rejection. A 400 for a bad email then counts as a pass, so boundary values, invalid input and per-role access all fit in one file.
Step 5: Keep the API honest with contract tests
A contract is what an API promises other teams. Contract tests check it keeps that promise:
The live API against its spec. Ask "Check QA against api/openapi.yaml" and every operation is called and checked for a documented status, its content type, its response schema and its required headers. Only read-only calls are sent unless you allow writes.
Breaking changes between versions. Ask "What breaks between api/openapi-v1.yaml and api/openapi-v2.yaml?" Removed fields, changed types and new required parameters are listed first.
Consumer-driven contracts with Pact. Generate a pact from the calls your web app makes, then verify the provider against it.
Beyond plain REST
The same conversation reaches the parts of a modern system that sit around a REST API:
Microservices. Wait until every service is up, authenticate service-to-service with OAuth2 client credentials or mTLS, and mock the services you depend on so you can test one service alone, then ask what the mock received.
Real-time and RPC. WebSocket, Server-Sent Events and gRPC calls.
Quick load checks. Put up to 200 concurrent callers on one endpoint and fail the run when p95 latency or the error rate goes over a threshold. It's a fast sanity check, not a replacement for a full performance-testing tool.
Step 6: Turn it into test code in your framework
Everything so far runs from the chat. To get tests your CI can run, ask for code:
Generate REST Assured tests for every request in the Shop API collection, including negative tests for missing auth and invalid input, then run them and fix any that fail.
The assistant reads your project, finds your framework and its conventions, writes the tests, runs them, and fixes them until they pass. It works with the framework you already use: REST Assured, pytest with requests, Playwright's request API, Cypress cy.request and others. No framework yet? Ask it to scaffold one: "Scaffold a REST Assured API test framework for this project."
Step 7: Run it on every commit
Generated API tests are plain code in your repository, so they run like the rest of your suite. Run them from the Test Explorer, put them on a schedule, or gate your builds with CI/CD Pipelines. Your pipeline makes one call, and the build waits for the verdict:
npx @testver/testver trigger --mapping "api-gate" --server https://testver.your-company.com --token $TESTVER_CI_TOKENTips for API tests that stay useful
Point it at a test environment and say so in the prompt. Start in Manual mode until you trust the flow.
Keep secrets in environment variables, never inline in a request. The assistant warns you if a literal secret is about to be saved.
Assert on shape and key fields, with a schema and a few JSON paths, rather than comparing whole bodies that change with every run.
Test the unhappy paths: missing or expired auth, bad input, not found, conflicts.
Run a contract check on every spec change before it ships.
Mock what you don't own, so a partner's outage doesn't turn your suite red.
Wrapping up
With Testver, API testing is one conversation instead of three tools: import the API, check responses by asking, chain real flows, drive them with data, hold the API to its contract, and finish with test code in your own framework that runs on every commit.
Learn more: every prompt, with examples
This post covers the main path. The API Testing with AI guide goes much further. It is a step-by-step tutorial in twelve lessons, from a first request through validations, chains, data-driven runs, contract testing, microservices, real-time APIs, gRPC and load checks, to test code in your framework. Every lesson has prompts you can copy, what happens when you send them, and what to look for in the answer. It ends with a catalogue of every kind of API test, each with a ready-made prompt.