API testing Available now

No screens? You still need verification.

Check order, payment, and member APIs against their contracts on every run. Evaluate schemas, status codes, and permissions per case, and include results in the same release decision as UI tests.

Request a demo Explore the platform

Server/API projects start directly with API testing, without screen collection.

API contract · Order serviceOpenAPI v3 · 24 endpoints

GET/orders/{id}200 · Schema matched · 84ms
POST/orders/{id}/cancel409 · 24-hour rule
POST/payments400 · Missing limit-exceeded message
GET/branches/{id}/orders403 · Cross-branch access blocked
PUT/members/{id}200 · Required fields validated

23 passed · 1 failedResponse schema · Status code · Permissions · Latency

What gets tested

The contract becomes the test case.

Define expected responses per endpoint and compare them with actual responses. Test more than the happy path: verify that invalid requests are rejected and access to other users' orders is blocked in the same run.

Response schema — Compare fields, types, and required values against the contract.
Status codes — Check success, rejection, and conflict codes against rules, such as a 409 response for cancellation after 24 hours.
Permissions — Verify that requests from other users or roles are blocked with 403.

POST/paymentsOpenAPI v3

Response schemaid · status · amount · receiptUrl
Status codes201 · 400 · 403 · 409
PermissionsBranch manager · Payment operator
Latencyp95 ≤ 800ms

Generated cases · 4

Amount above the limit400 + guidance message
Pay for another branch's order403
Already-paid order409
Successful payment201 · Schema matched

Cases and execution

Cases come from three sources.

Create API cases just like UI cases: draft from requirements and repository code, then add human-authored cases. When a PR opens, Qoretix suggests new, updated, or removed cases for changed endpoints. Only approved suggestions enter the suite.

Document-based — Extract inputs and expected results for each endpoint from feature lists and requirements.
Code-based — Derive error paths and boundary values from routes, handlers, and input validation logic.
PR suggestions — Analyze changes and suggest cases for the owner to approve or reject.
Automation rules — Run on every push and PR using repository, branch, and changed-path rules.

PR #142Add a payment methodSuggested: 2 new · 1 update · 1 removalApproveReject

Scenario	Priority	Automation	Source	Language
Session expiry after login	High	Automated	Document	KO EN JA
Payment amount validation — zero, negative, limit	Critical	Automated	Document	KO EN JA
Block access to another branch's orders	High	Automated	Code	KO EN JA
Order list pagination	Medium	Automated	Document	KO EN JA
New payment method · Card expiry validation Awaiting approval	High	Automation candidate	Code	KO

Shared checklist: 13 / 17

Results and decisions

Every failed call retains its request and response.

Every failed case includes the request, response, and execution log. If a payment API omits a limit-exceeded message, you can see exactly which field was empty. Severity determines the release decision.

Any critical or major failure results in FAIL.
Only minor or trivial failures result in CONDITIONAL, requiring a person to review and decide.
Tests with inconsistent results on the same commit are quarantined. They keep running but cannot cause FAIL; that run is CONDITIONAL.
Failures automatically become Jira issues linked to retest results.

Release decisions and coverage

Checks

What one run verifies.

Combine checks to define expected results for each case. If any expectation fails, the case is recorded as failed.

Response schema

Compare field names, types, required values, and nested structures against the contract.

Status codes

Verify that each situation returns its expected code, such as 200, 201, 400, 403, or 409.

Permissions & roles

Make requests with registered test accounts and verify unauthorized roles are blocked.

Error messages

Check that rejection responses include a reason and guidance.

Data integrity

Verify that retrieved values match created data and that cancellation changes the state correctly.

CI pipeline execution

Run as a GitHub Actions workflow step and receive results for every PR.

API specification integration Preview

Release gating Preview

Fail PR checks or block deployment when the decision is FAIL.

Frequently asked questions

Before you adopt API testing

Can we use it for server/API projects with no screens?

Yes. Once connected, the repository is classified automatically and screen collection is skipped for API projects. Register the target URL and test account login details to start.

Is an OpenAPI specification required?

No. Build your suite from document- and code-based drafts plus cases written by your team. Directly importing endpoints and schemas from a specification is available in preview.

Does it replace unit tests or CI pipelines?

No. Keep your unit tests and add API contract testing as a GitHub Actions step. Runs follow pushes and PRs, with results consolidated into the release decision.

Do you access production data?

We recommend staging and make calls only with registered test accounts. We do not require production database or production account credentials.

What do people handle?

Owners approve PR suggestions and review CONDITIONAL decisions. With managed QA, experts review contract cases, triage failures, and retest after fixes.

Are API results separate from UI results?

No. They appear in the same run and report. API and UI failures contribute to one release decision, with security results alongside them.

Start with one endpoint.

Connect your repository and target URL to reach the first run in typically five minutes. See how API contract test results become a release decision in a demo.

Request a demo Implementation consultation

sales@qoretix.com +82-33-242-0210Weekdays, 10:00–18:00 KST