API testing

The UI looked fine.
Your API broke.

A dedicated AI agent for your backend – it turns plain-language goals into HTTP requests and validation code, runs them in an isolated sandbox, and hands you the evidence. 

Get a demo

Trusted by high-performing engineering teams at:

Lovable
Nordea
Pricer
AstraZeneca
Upsales
Sambla Group
AdminPulse
MeetingPackage

Your APIs, tested the same way
as everything else

API testing in QA.tech runs as its own application type, alongside web and mobile, so one suite covers all three. You write what should happen in plain English. The agent makes the real HTTP calls, checks the responses, and returns a pass or fail with the full request trace. No collection files to maintain, no scripts, no browser.

When the product is the API

Some products are a proxy server and a customer-facing API, with the dashboard only showing results. Testing through the UI verifies almost nothing, because the thing that can break never renders.

Finding what actually ran

When a calculation misfires, someone goes digging: which request ran, with what payload – usually after the wrong number reached a customer. A test asserting on request and response catches it first.

Postman collections drift too

Collections and pytest files hardcode tokens, drift from the real contract, and pile up until nobody dares delete one. The maintenance problem didn't go away when you skipped the browser. It just moved.

320h/mo
QA time saved

"We have replaced over 320h of manual testing every month with QA.tech."

Fredrik Seidl
Fredrik Seidl – CTO at Upsales
Upsales is a SaaS platform for CRM, marketing automation & Sales in B2B. ~150 employees.
Read their story

What the API agent actually does.

Plain-language API testing

You give a test a name, a goal and an expected result. The agent makes the requests, then writes and runs code in its sandbox – shell, Node.js, Bun or Python – to check the response: status codes, required fields and their types, the values you named.

  • You never write or maintain the validation code
  • Every command it ran sits in the trace with its output
  • Optional steps when you want later runs more prescriptive

Multi-step flows that carry data forward

Create an entity, read the generated id out of the response, fetch it back, confirm the persisted values. The agent saves response bodies, parses them and reuses ids in later requests. A real API workflow fits in one test instead of a chain of brittle exports.

  • Token and id passing between steps
  • Conditional follow-up calls based on what came back
  • One test per workflow, not per endpoint

Failing on purpose is a passing test

Responses are evidence, including error responses. “Calling GET /account with an expired token returns 401 with an error message” is a test the agent runs and passes on the 401.

  • Negative auth: expired and invalid tokens rejected correctly
  • Validation contracts: the 422 with a field-level error
  • State the expected rejection and the error becomes the proof

Every request and command, captured

Every request is captured with method, URL, status, headers, payload and response. Every generated command is captured with its output, error output and exit status.

  • Filter to failures only when triaging a run
  • Read exactly what the agent executed
More on PR testing

Use cases teams start with.

Keep a small scheduled suite of contracts that must never break, and let dynamic tests on each pull request cover what changed. These are the places teams point the API agent first:

API regression testingAPI contract testingAnalytics & tracking eventsAuth & token rejectionPR & CI/CD gatesMulti-environment runs

Everything a backend check needs to run unattended.

Triggered from your pipeline

Run API tests on every pull request, after a deploy, or on a schedule via the REST API or CLI.

Sandboxed code execution

The agent writes and runs validation code against the real response body in shell, Node.js, Bun or Python.

Full run trace

Method, URL, status, headers and bodies on every call, plus every command with its output and exit status.

Credentials as  variables

Keys live in a Custom Fields config, reach the sandbox as env vars, and stay redacted in traces and cURL exports.

Locked-down endpoints

Your API stays on https, and every run surfaces its outbound IP so allowlisting QA.tech's traffic is one entry.

Alerts where you work

Slack and Teams notifications on completion or failure, per project or per plan.

Your backend ships daily. Test it like it.

See a QA.tech agent call your API, run code against the response and prove the contract, live, in a 30-minute demo.

Get a demo

Frequently asked questions

Can't find what you're looking for? Reach out.

Do I need to write any code?
No. Tests are a name, a goal and an expected result in plain language, with optional steps if you want later runs more prescriptive. The agent writes and executes the validation code itself, and the trace shows exactly what it ran.
Where do API keys and tokens live?
In a Custom Fields config, delivered to the sandbox as environment variables. They are never pasted into test instructions, never printed in commands, and redacted in traces and cURL exports. Use dedicated test credentials with minimum access.
Can it test APIs behind our firewall?
The API needs to be reachable over https from the public internet, but you can restrict it to QA.tech's traffic: every run surfaces its outbound IP for allowlisting.
Can it test error handling?
Yes, and it should. State the expected rejection – “invalid payload returns 422 with a field-level error” – and the error response is the passing evidence.
Is this contract testing, load testing, or security testing?
Functional and contract-style testing: status codes, response shape, required fields, multi-step workflows and negative cases. It is not a load or penetration testing tool.
How do runs get triggered from CI?
Through the REST API or the CLI – on every PR, on deploy, or on a schedule. API test plans trigger the same way as web and mobile plans.