Status-code assertions
The documented success response becomes the baseline assertion for the operation, so a silently changed status code fails the run rather than passing quietly.
OpenAPI & Swagger importPer-operation coverageA REST API of our own
Your spec already says
what should be true.
An OpenAPI document is a contract nobody tests. QAEverest reads yours — file or live URL — and turns every path, method, schema and security scheme into the cases that prove it holds: status, shape, negatives and auth, chained into a suite you can run per environment. The same capability is available the other way round, over a documented REST API of our own.
GET/orders4 cases200schema401
POST/orders6 cases201required422
GET/orders/{id}5 cases200404schema
DELETE/orders/{id}4 cases204403idempotent
Chained into one suite — the id created by POST feeds the GET and DELETE that follow it.
2
Ways to bring a spec in
Upload the OpenAPI or Swagger document as a file, or point QAEverest at a live spec URL behind your own auth header
1 : n
Operation to coverage
Every path and method in the document becomes its own set of positive, negative and schema-validation cases
16
Endpoints on our own API
Generation, scanning, suite building, execution and reporting — the same contract our IDE plugins call
qae_
One key, every service
Sent as x-api-key or a Bearer token, metered per unit against your balance and written to your usage log
Spec To Coverage
Four steps between a document and a green run
Importing is deliberately boring — the interesting part is what the parser pulls out of the document and how little you have to restate by hand.
1
Import
Drop in a Swagger or OpenAPI document, or hand over the URL your service already publishes it at
2
Parse
Paths, methods, parameters, request and response schemas and declared auth schemes are read out of the document
3
Generate
Each operation turns into cases — happy path, negatives, edge values and response-shape assertions
4
Execute
Promote the cases into a chained suite and run it per environment with injected data and stored variables
What the parser reads
Paths and operations
Every path item and each method under it becomes a separately addressable unit of coverage — nothing is collapsed into a single “API” test.
Request and response schemas
Typed bodies give the generator the required fields, formats and enums it needs to write both the valid call and the ones that should be rejected.
Declared security schemes
The auth the spec declares becomes test material of its own: authorised calls, missing credentials and credentials that shouldn’t be enough.
Parameters and examples
Path, query and header parameters — plus any examples the document carries — seed the data used across the generated suite.
Accepted inputs
OpenAPI documentJSON or YAML, uploaded as a file
Swagger documentThe same import path — older specs are not a special case
Live spec URLPoint at the endpoint your service already publishes
Postman collectionFor teams whose contract lives in a collection instead
Organisation admins control whether spec import is available to their users, so an enterprise account can keep the surface closed until it chooses to open it.
Per Operation
Six things every operation gets tested for
A spec import that produces one smoke test per endpoint isn’t coverage. These run for each documented operation, from both sides of the contract.
Response-schema validation
Payloads are checked against the shape the spec promises — a dropped field or a string where a number was declared is a failure, not a warning.
Negative and edge cases
Required fields are omitted, enums are violated and boundary values are pushed, so the contract is exercised from the wrong side as well as the right one.
Auth and permission paths
Calls run without credentials and with the wrong ones, confirming that protected operations actually reject what the spec says they should.
Chained data injection
A value returned by one call feeds the next, so create-then-read-then-delete flows run as one suite instead of four disconnected requests.
Environment-scoped runs
The same generated suite runs against Dev, QA and Prod by swapping the base URL and stored variables — the spec is imported once.
The Other Direction
QAEverest is itself an API you can call
Everything above is reachable programmatically. Our IDE plugins, the MCP server and the Jira app are all clients of the same public v1 surface — there is no privileged internal path they use and you don’t.
EndpointPurposeCredits
POST
/api/v1/auth/tokenExchange a qae_ key for a short-lived access token—GET
/api/v1/whoamiIdentify the presented key and what it is allowed to do—GET
/api/v1/usageCredits remaining, request quota and current per-call ratesfreePOST
/api/v1/generate-testcasesStory text → structured test cases1POST
/api/v1/api-tests/generateStory or spec → an API test suite2POST
/api/v1/ui-testsStart a UI generation job5GET
/api/v1/ui-tests/{jobId}Poll that UI job until it completes—POST
/api/v1/mobile-testsStart a mobile generation job5GET
/api/v1/mobile-tests/{jobId}Poll that mobile job until it completes—POST
/api/v1/security-scanHeader, SSL/TLS and vulnerability scan of a URL10POST
/api/v1/performance-testLoad, stress, spike or soak run10POST
/api/v1/suites/buildDocument or requirement text → a runnable suite in one callmeteredGET
/api/v1/suitesList your automation suites with id, title, type and count—POST
/api/v1/executeStart a run — returns 202 while it continues server-sidemeteredGET
/api/v1/execute/resultsLatest pass/fail outcome for a suite—GET
/api/v1/execute/reportFetch the run report for a completed execution—Endpoints marked — don’t consume credits. Generation and scanning are metered per unit at the rates set on your account, and metered means the charge depends on what the call ends up producing. Every call is written to your usage log either way.
Authentication
Send your key on every request in whichever form your client prefers.
x-api-key: qae_••••••••••••
# or, equivalently
Authorization: Bearer qae_••••••••••••Clients that would rather not hold the key long-term can exchange it atPOST /api/v1/auth/token for a short-lived access token — the route the MCP server takes. QAEverest stores only a hash of the key itself; the raw value is shown once, at generation.
GET /api/v1/whoami is the one endpoint that accepts both an account key and a personal key — clients call it on connect to learn what the presented credential may actually do.Sync, async and 202
syncTest-case and API-test generation, security scans and performance runs answer in the response body.
jobUI and mobile generation return a job id — poll
/ui-tests/{jobId} or /mobile-tests/{jobId} until it resolves.202Execution returns immediately while the run continues server-side; read
/execute/results for the outcome.POST /api/v1/suites/build runs the AI engine twice — generate, then step-generate — so give that one a long client timeout.One error shape, five things it tells you
Failures come back as { success: false, error: "…" } with a status that says which of your problems it is — never a bare 500 you have to guess at.
400
Bad request
A required field is missing — the message names it, e.g. “suite_id” or “suite_title” is required.
401
Unauthorised
The key is absent, unrecognised, expired or revoked. Revocation takes effect on the next request.
402
Insufficient credits
The response states the per-unit rate for the service and the balance you actually have left.
403
Service not enabled
That capability isn’t switched on for your account — a deliberate, readable refusal rather than a silent empty result.
429
Quota reached
The monthly request limit for your plan is exhausted; it resets on the next billing cycle.
See It In Action
Point us at an OpenAPI or Swagger document and preview the per-operation coverage QAEverest writes out of it — before a single case is generated against your own account.
The coverage generated from your spec will appear here.