DEV Community: Liudas

Rentgen v2: AI testing grounded in actual API test results

Liudas — Wed, 28 Oct 2026 19:11:07 +0000

I released the first version of Rentgen on November 9, 2025. On October 28, 2026, we released v2.0.0.

The original workflow remains simple:

Paste a cURL → map the fields → run API tests.

Rentgen generates and executes deterministic checks for input validation, boundaries, authentication, security, and performance. That core workflow runs locally, is free, and requires no AI model.

Version 2 adds AI analysis and additional test generation, OpenAPI import, and a more compact interface.

Why add AI to an existing test engine?

After Rentgen finishes a run, it already has useful context:

The original request.
Field types, required fields, allowed values, and boundaries supplied through mapping.
Requests that were actually executed.
Actual responses and measurements.
Configured expectations and test results.

That gives a model a specific task: analyse the recorded results and identify meaningful gaps in coverage.

For example, testing a required field with null does not establish what happens when the field is omitted entirely. A server error from a request that changed several fields may warrant a new test that isolates one condition.

The goal is to find useful next steps based on what has already happened.

Deeper AI Testing

Rentgen v2 supports connections to:

OpenAI.
Anthropic.
Ollama, including models running locally.

You configure your provider and model connection. Rentgen prepares the analysis request automatically, so there is no prompt to write.

The analysis returns:

A summary of observed API behaviour and coverage.
Up to three important findings, with evidence and impact.
Areas that need further investigation.
Up to ten additional executable tests covering meaningful gaps.

Ten is a limit, not a target. If only two useful tests remain, generating eight more variations adds noise.

You can also provide additional API context, such as business rules or areas you want investigated.

Generated tests become part of your project

The output is structured test data that Rentgen can use directly.

You can inspect each proposed request, review its expected result, and execute it in Rentgen.

AI helps discover a test, then the test runner executes and checks request deterministically.

The model’s suggestion still needs review. It can misunderstand a business rule or propose an incorrect expectation. Rentgen lets you inspect and adjust the test before making it part of your ongoing coverage.

Your model connection

AI requests go directly from your device to the provider you configure.

Rentgen has no backend receiving your API requests, reports, or model credentials. Credentials are stored locally.

If you connect a local Ollama model, analysis can stay on your own machine. If you choose a cloud provider, the supplied context goes to that provider.

OpenAPI import

You can now import an OpenAPI JSON file or provide its URL.

Rentgen creates a folder and collection of endpoint requests from the specification. This gives you a starting point for configuring and testing an API without importing each request individually.

You still supply the environment, credentials, and any values needed to make those requests work.

A more compact interface

Version 2 reorganises test results into tabs:

Deeper AI Testing.
Security Tests.
Performance Insights.
Data-Driven Tests.
CRUD.

This makes larger runs easier to navigate and keeps each suite’s results together.

The release also includes the QUERY method, GUID field mapping, expanded numeric ranges, fixes for mapping persistence after errors, and other usability and stability improvements.

What remains free?

The deterministic API testing engine remains free.

Deeper AI Testing is an optional Rentgen Pro feature, priced at $36 per year. You bring your own model connection; cloud model usage is billed separately by your provider.

Try Rentgen v2

Download Rentgen, import a cURL or OpenAPI specification, configure the fields, and run the deterministic tests.

If you try the AI integration, I’m particularly interested in whether its additional tests find something useful beyond the existing coverage.

A big thank you to Andrej Davidovič for building features with me and helping bring this release together.

I got tired of API testing comparison tables. So I built REST Atlas.

Liudas — Tue, 27 Oct 2026 18:34:58 +0000

There is something amusing about API testing tool comparisons: the tool publishing the comparison almost always comes out looking like the best choice.

Sometimes the information is accurate. The problem is which information makes it into the table.

Choose the right columns, leave out a few inconvenient capabilities, give your own terminology a dedicated row, and the result becomes fairly predictable.

As someone who builds an API testing tool myself, I understand how this happens. You spend your time solving a particular problem, so naturally you consider that problem important. Your comparison starts reflecting your product’s priorities.

That can help explain a product. It becomes less useful when someone is trying to understand the wider ecosystem.

I wanted a place where I could explore REST API testing tools, apply consistent filters, and compare their documented capabilities using the same fields.

I found directories, GitHub lists, articles, and broader ecosystem maps. Several were useful, but I couldn’t find one that worked the way I wanted.

So I built REST Atlas.

A place to explore the REST API testing ecosystem

REST Atlas is an interactive map and directory of tools that support REST API testing.

You can browse tools by category, search for particular capabilities, filter the directory, and compare tools side by side.

The catalogue covers different parts of the work:

API clients
Functional testing
Test generation
Contract and schema testing
Security testing
Performance testing
Mocking
Traffic recording and replay
Monitoring

A tool can belong to several categories. That matters because the boundaries are rarely clean. An API client might also run automated tests, provide mocks, and execute scheduled checks.

The comparison includes practical information such as licensing, pricing model, interfaces, execution options, test creation, and CI/CD support.

Those details often matter more than another generic “best API testing tools” article. A team that needs local execution and version-controlled test assets has different constraints from a team looking for hosted monitoring.

The aim is to make those differences easier to see.

Consistent criteria, with sources people can check

Calling a comparison “objective” is easy. Keeping the information accurate takes work.

The starting principles for REST Atlas are:

The same comparison fields apply to every tool. Adding another product does not create a special set of columns designed around its strengths.

Entries include sources and a verification date. Readers should be able to check where the information came from and see when it was last reviewed.

Unknown information stays unknown. Missing evidence should not automatically become a red cross. “Not confirmed” and “not supported” mean different things.

Licensing and pricing are separate. A free plan does not make a product open source. A public repository can have restrictions. An open-source core can coexist with paid editions.

The catalogue also needs to describe the scope of each entry carefully. A desktop application, its open-source core, and the vendor’s hosted platform may have different capabilities and terms.

These distinctions make the data harder to maintain, but they make the comparison more useful.

No advertising or sponsored placements

REST Atlas has no advertising, sponsored tool placements, analytics, cookies, or tracking.

You can browse, filter, and compare without creating an account.

For transparency, I am the founder of Rentgen, and the REST Atlas repository lives under the Rentgen-io GitHub organization.

Rentgen is included in the catalogue. The same fields, source requirements, and contribution rules apply to it.

That relationship should be visible to anyone evaluating the project.

The catalogue is open to contributions

I started with tools I know. There will be tools missing, details that need correcting, and capabilities that change after an entry is reviewed.

The repository is public so people can help improve it.

All tool data lives in a single tools.json file. The application reads that file to build the directory, map, filters, and comparisons. Adding a tool does not require changing the application code.

To contribute:

Read CONTRIBUTING.md for the supported fields and formats.
Add or update an entry in tools.json.
Open a pull request with sources supporting the information.

Tool authors are welcome to contribute. So are people who use the tools and notice something missing or inaccurate.

Suggestions for better comparison criteria are welcome too. Consistent fields are useful only if they help people make real decisions.

For now, the scope is deliberately focused on REST API testing. Tools that support several protocols can be included when they also support REST.

I would rather maintain a useful, focused catalogue than keep expanding its scope until the details become impossible to follow.

If you work with REST APIs, try it with a few tools you already know. Check whether the comparison represents them accurately. Add a missing tool, correct an entry, or suggest a field that would help you choose.

Explore: restatlas.org

Repository and contributions: github.com/Rentgen-io/rest-atlas

API! API! API! 👏

Liudas — Mon, 19 Oct 2026 07:35:50 +0000

If you’ve been working in software long enough, you probably understand Steve Ballmer’s enthusiasm. 😄

APIs are everywhere.

Mobile applications communicate with backend services through APIs. Websites retrieve and modify data through APIs. Enterprise systems exchange information through APIs. Cloud platforms expose almost everything through APIs, and even physical devices increasingly provide APIs for integration and automation.

The graphical interface may be what the user sees, but in many systems, the real work happens underneath it.

I started testing APIs around 2008. Almost two decades later, the technologies have changed enormously, but many of the problems haven’t.

Unexpected inputs. Incorrect access decisions. Broken HTTP semantics. Server errors. And, of course, the legendary 200 OK when absolutely nothing is OK.

In 2017, Dylan Beattie even turned these frustrations into a brilliant parody of Bon Jovi’s You Give Love a Bad Name, called You Give REST a Bad Name.

Some API problems are apparently timeless. 😄

And that’s exactly why we build https://rentgen.io

API! API! API! 👏

API Regression Testing: Turn Every Production Bug Into a Reusable API Test

Liudas — Thu, 08 Oct 2026 08:32:47 +0000

A production API defect should surprise you only once.

Every production bug reveals an assumption that was not tested. After fixing it, reproduce the original request, verify the correction, and turn the scenario into a reusable API regression test.

This is especially important for:

API authorization failures
Input validation bugs
HTTP protocol errors
API performance issues
Pagination problems
Security vulnerabilities
Data integrity failures
Third-party integration defects A code fix solves the problem today. A reusable API test helps prevent the same defect from returning in a future release.

The goal of API testing is not only to find and fix bugs. It is also to preserve what the team learned and continuously expand the system’s regression coverage.

This is the tenth rule in The Power of Ten Rules for Testing HTTP APIs.

Read the complete article: https://qaontime.com/research/the-power-of-ten-rules-for-testing-http-apis.html

Your API Can Create the Customer—and Still Be Broken

Liudas — Tue, 06 Oct 2026 10:03:53 +0000

A successful POST /customers response does not prove that your API is correct.

It only proves that one business operation worked under one specific set of conditions.

Modern APIs are not just business functions. They are also implementations of a communication protocol. Clients depend on more than the response body:

HTTP methods
status codes
request and response headers
content types
authentication behavior
caching directives
content negotiation
idempotency
consistent error handling When these rules are violated, the API may appear healthy during a happy-path test while still breaking clients, integrations, SDKs, proxies, gateways, or production workflows.

A simple example

Imagine a customer API that correctly supports:
POST /customers GET /customers/{id} PUT /customers/{id} DELETE /customers/{id}

The main business scenarios work. Customers can be created, retrieved, updated, and deleted.

But what happens when you test the protocol around those operations?

Does PATCH return an appropriate response if it is unsupported?
Does OPTIONS describe the endpoint correctly?
Does HEAD behave consistently with GET?
Is an invalid Content-Type rejected?
Is an unsupported Accept header handled correctly?
Are authentication failures represented consistently?
Are cache directives present where they should be?
Does repeating an idempotent request produce a predictable result?
Do all endpoints return errors in a consistent format?

These are not cosmetic details. They are part of the API contract.

Business logic is only half the API

A common testing pattern is:

Send a valid request.
Check for 200 or 201.
Verify a few fields in the response.
Move on.

That test may be useful, but it covers only one path through the system.

An API consumer also relies on predictable protocol behavior. For example, a client may use:

Content-Type to describe the request body;
Accept to negotiate the response format;
status codes to decide whether to retry;
headers to control caching;
authentication responses to refresh credentials;
idempotency guarantees to safely repeat operations.

If those behaviors are inconsistent, the business operation can still succeed while the integration remains unreliable.

The infrastructure excuse

One of the most common assumptions is:

“The framework, API gateway, or infrastructure handles that.”

Sometimes it does. Sometimes it does not. Even when a framework provides defaults, the final behavior may be changed by:

custom middleware;
reverse proxies;
gateway configuration;
authentication layers;
endpoint-specific code;
error handlers;
caching policies;
deployment differences.

The API consumer does not care which layer caused the behavior. They experience the final HTTP response.

That is why protocol behavior needs to be tested at the API boundary.

What protocol-level API testing should cover

At minimum, test both valid and invalid protocol usage:

HTTP methods
Verify supported methods and confirm that unsupported methods return appropriate responses.

OPTIONS and HEAD
These methods are often ignored, incorrectly configured, or inconsistent across endpoints.

Content-Type
Check whether the API rejects unsupported, missing, or misleading content types.

Accept and content negotiation
Test how the API behaves when clients request supported, unsupported, or malformed response formats.

Authentication behavior
Do not test only successful authentication. Also verify expired credentials, missing credentials, invalid tokens, insufficient permissions, and consistent error responses.

Response headers
Headers can affect caching, security, client behavior, observability, and interoperability.

Caching directives
Check whether Cache-Control, ETag, Last-Modified, and related behavior match the endpoint’s requirements.

Idempotency
If an operation is expected to be idempotent, repeat it and verify that the outcome remains predictable.

Error consistency
Equivalent protocol failures should not produce completely different response formats depending on which endpoint was called.

Why this matters

Protocol defects often survive ordinary functional testing because the happy path does not expose them.

They may only appear when:

a mobile client sends a different header;
an SDK retries a request;
a proxy caches a response;
a browser sends an OPTIONS request;
a client negotiates a different representation;
a token expires mid-flow;
an integration uses an unsupported method;
a request is repeated after a timeout.

At that point, the API may be “functionally correct” according to its internal business logic, but incorrect from the consumer’s perspective.

That is still a defect.

A practical rule

When testing an endpoint, do not ask only:

“Did the operation work?”

Also ask:

“Did the API behave correctly as an HTTP protocol implementation?”

This changes the test mindset from checking isolated outcomes to examining the full contract around every request.

Where Rentgen fits

Rentgen is designed to explore this space before teams invest time in large automation suites.

Starting from a single request, it can generate structured checks around:

invalid input;
boundary values;
missing fields;
malformed payloads;
header variations;
authentication behavior;
method handling;
protocol-level edge cases.

The goal is not to replace contract tests, integration tests, or CI regression suites. The goal is to expose assumptions early—before they become permanent gaps in the test strategy.

Final thought

An API is not correct merely because it can create a customer.

It is correct when it behaves predictably across the protocol that consumers depend on.

Test the business logic—but test the protocol around it too.

Read the complete white paper: https://qaontime.com/research/the-power-of-ten-rules-for-testing-http-apis.html

API Abuse Prevention: API Testing Rule 8/10

Liudas — Mon, 05 Oct 2026 04:14:55 +0000

A valid API request can still take down a service.

API abuse is not always malicious. Retry storms, broken integrations, excessive polling, misconfigured automation, and large data requests can generate enough traffic to exhaust shared resources. Each request may be valid on its own, but the combined effect can increase latency, consume database connections, and reduce availability for every other consumer.

Every API should defend itself against excessive resource consumption. API testing should cover rate limits, quotas, expensive operations, concurrent requests, large-volume retrieval, retry behavior, resource exhaustion, and fair allocation between consumers.

For example, an expensive search or report endpoint may work correctly under normal traffic but become a serious reliability problem when a client repeatedly calls it hundreds of times per second. The same applies to endpoints that return large collections or allow aggressive polling without meaningful restrictions.

Protection may be implemented in the application, API gateway, infrastructure, or a combination of these layers. What matters is the observable result: one consumer must not be able to significantly degrade availability for everyone else.

Testing should verify not only that limits exist, but also that the API responds predictably when those limits are exceeded. Clients should receive clear failure responses, while the service remains stable and available.

An API that assumes all consumers will behave correctly is an API that has not been fully tested.

This is Rule 8 of The Power of Ten Rules for Testing HTTP APIs. Read the complete research article for the full explanation and testing guidance: https://qaontime.com/research/the-power-of-ten-rules-for-testing-http-apis.html

Rentgen is an API discovery tool built to reveal behavior beyond normal usage assumptions and expose reliability risks before they become production incidents.

Automation Before Automation.

Idempotency and Concurrency in APIs: API Testing Rule 7/10

Liudas — Fri, 02 Oct 2026 09:45:25 +0000

A payment request that works once may still charge the customer twice.

State-changing API operations must be tested beyond the first successful request. Creates, updates, transfers, and deletes can behave incorrectly when clients retry after a timeout, replay a completed request, or send identical operations concurrently.

API testing should verify repeated requests after success, retries after lost responses, concurrent requests using the same idempotency key, different updates against the same resource, and updates based on stale data. The expected behavior may be deduplication, conflict detection, serialization, or returning the original result, depending on the API contract.

For payment APIs, reusing the same idempotency key and request must not create a second transaction. The same protection should work when identical requests reach different service instances at the same time. Similarly, concurrent updates must not silently overwrite valid changes made by another client.

Do not verify only the HTTP response. Inspect the final resource state, transactions, emitted events, audit records, external side effects, and asynchronous jobs. Two successful responses must not create duplicate payments, repeated orders, lost updates, or partially completed operations.

Testing idempotency, retry safety, replay protection, and concurrency is essential for reliable APIs and distributed systems. Rentgen is an API discovery tool built to test what an endpoint actually does beyond one successful request.

Read the complete API testing white paper: https://qaontime.com/research/the-power-of-ten-rules-for-testing-http-apis.html

Automation Before Automation.

API Testing Rule 6/10: APIs Must Fail Predictably

Liudas — Wed, 30 Sep 2026 12:40:07 +0000

API failures are inevitable, but they should never be unpredictable. Invalid requests, missing resources, authentication failures, rate limits, dependency outages, and internal errors are different conditions. They should return different and meaningful HTTP status codes instead of collapsing into a generic 500 Internal Server Error.

Predictable API error handling allows clients to understand what happened and decide whether to fix the request, authenticate, retry later, or stop. Similar failures should produce consistent status codes, stable error structures, and useful messages without exposing sensitive implementation details.

For example, a missing resource should return 404 Not Found, a malformed request should return 400 Bad Request, and a rate-limited client should receive 429 Too Many Requests. A 500 Internal Server Error should indicate that the server failed while processing an otherwise valid request—not that the client submitted invalid data.

API testing should cover validation errors, missing resources, authentication and authorization failures, unsupported operations, rate-limit violations, timeouts, dependency failures, and unexpected internal errors. Testers should verify that error responses are consistent, actionable, secure, and easy for API clients to interpret.

Any reproducible request that consistently generates a 5xx response should be investigated as a potential defect. Reliable APIs are not defined only by successful responses. Predictable failure handling is a core part of API reliability, REST API design, and software quality.

Rentgen is an API discovery tool built to explore failure paths beyond the expected request and expose assumptions before they become production incidents.

Read the complete API testing white paper: https://qaontime.com/research/the-power-of-ten-rules-for-testing-http-apis.html

Automation Before Automation.

API Testing Rule 5/10: Every Collection Endpoint Must Have Bounded Results

Liudas — Tue, 29 Sep 2026 10:16:12 +0000

GET /customers may work perfectly with 100 records. But what happens when the dataset grows to one million?

Pagination alone is not enough. Collection endpoints should enforce a maximum page size and predictable defaults. API testing should verify what happens when pagination parameters are omitted, extremely large limits are requested, complex filtering and sorting are combined with pagination, or large collections are retrieved repeatedly.

Without server-enforced limits, a single valid request can consume excessive database, memory, network, and client resources. An endpoint that returns unbounded results is a scalability and reliability defect waiting to become a production incident.

In the complete white paper, we explain how to test pagination, maximum page sizes, cursor-based navigation, filtering, sorting, performance under large datasets, and protection against excessive requests.

Read the complete white paper: https://qaontime.com/research/the-power-of-ten-rules-for-testing-http-apis.html

Automation Before Automation.

API Testing Rule 4/10: Authentication Authorization

Liudas — Mon, 28 Sep 2026 06:53:05 +0000

A valid token proves identity, not permission.

Testing whether a user can access their own profile is not enough. Repeat the same request with another user’s resource ID and verify that access is denied.

Check different roles, owned and unowned resources, cross-tenant access, read/update/delete operations, and predictable IDs.

Authentication can work perfectly while authorization fails completely.

Rentgen helps discover these issues by testing API behavior beyond the expected authenticated request.

Read the complete white paper:https://qaontime.com/research/the-power-of-ten-rules-for-testing-http-apis.html

Automation Before Automation.

I Made a Physical Notebook for Software Testers. Yes, in 2026.

Liudas — Fri, 18 Sep 2026 17:51:40 +0000

We have Jira. Notion. Confluence. Test management systems. AI assistants. Automated test suites running in CI/CD. So naturally, I made a paper notebook.

Not because I suddenly became nostalgic for the 1990s, and definitely not because I think QA teams should start documenting test cases with a pen. The reason is much simpler: after many years in software testing, I still find that some of my best testing happens before I open another tool.

When I start testing something new, I usually need to understand the problem first. What changed? What can go wrong? What assumptions are we making? What don't I understand yet? What did I just observe that looks strange?

And somewhere between Slack, Jira, browser tabs, API clients, DevTools, and documentation, those thoughts disappear surprisingly quickly. So I created the QA Notebook.

This is not a test case repository. That was probably the most important rule when I started designing it. I didn't want another place where a tester writes:

Step 1: Click Login
Step 2: Enter username
Step 3: Enter password
Expected result: User is logged in

We already have enough tools for storing things like that. I wanted something for the part of testing that happens before everything becomes structured and repeatable. Each testing session starts with a few simple questions: What am I testing? What changed? What can go wrong? What are the known risks? What did I learn? What is still uncertain? And finally: Do I have enough confidence to move forward?

Yes. No. Or with known risks.

The page next to it is intentionally mostly empty. Because testing doesn't always fit into predefined fields. Sometimes you need to draw a flow. Sometimes you write down three API responses. Sometimes you discover a weird state transition and draw arrows everywhere. Sometimes you have a hypothesis that turns out to be completely wrong ten minutes later. That's fine. The notebook should help the investigation, not force the investigation to fit the notebook. Good testing starts with questions, not test cases

One thing I've tried to put throughout the notebook is small reminders that interrupt the usual testing routine.

For example: A 200 OK response can be a bug.
Test what developers didn't think about.
Every assumption is a potential test case.
If the UI prevents something, check whether the backend prevents it too. A passing test only tells you what happened under one set of conditions.

These aren't supposed to be profound quotes hanging on an office wall. They're there because sometimes one question is enough to send your testing in a completely different direction.

You might be testing a perfectly normal form, see a reminder about boundaries and suddenly try the value just above the documented maximum.

You might be testing permissions and notice: A disabled button is not an authorization control. So instead of stopping at the UI, you inspect the API. That is exactly what I wanted this notebook to do: occasionally give the tester one more idea. Bugs need investigation, not just tickets. I also added dedicated bug investigation pages.

When something strange happens, my first instinct isn't necessarily to immediately create a Jira ticket. First I want to understand what I actually found.

What happened? What did I expect? Can I reproduce it? What changed? What evidence do I have? What am I assuming? What is the smallest reproducible case? That last question is particularly useful.

A giant broken workflow involving twelve steps, three users and two services isn't very helpful if you can reduce the same problem to one request. So the investigation pages have space to work through that before turning the finding into a polished bug report.

I also wanted the notebook to generate testing ideas. There are reference sections scattered through it rather than putting 150 pages of blank templates together and calling it a QA notebook.

There's SFDIPOT for when you think you've run out of things to test: Structure, Function, Data, Interfaces, Platform, Operations and Time.

There are reminders to look beyond functional behavior into performance, security, reliability, usability, accessibility, compatibility, scalability, recoverability, availability, localization and observability.

There are sections specifically about API testing: authentication, authorization, input validation, headers, CORS, status codes, rate limits, oversized requests and other things that are very easy to forget when the happy path works perfectly.

Toward the end I added practical reminders about decision table testing and state transition testing, because interesting bugs often don't live in a single condition or state. They live in combinations and transitions.

The notebook ended up being 162 pages, but the goal was never to create a QA textbook. It's something that should sit next to the laptop while you're actually testing.

Why paper? This is probably the strange part.

I work in IT. I build automation. I use AI. I write Playwright tests. I work with APIs and CI/CD. And I still like writing things down.

There is something different about having a notebook open next to the keyboard while investigating a system. I don't have to decide where the note belongs. I don't need to create a ticket. I don't need to format anything. I don't need another browser tab. I can just write: "Why did this return 200?" Circle it. Test something else. Come back to it twenty minutes later. Maybe it becomes a bug. Maybe it becomes a test. Maybe it becomes nothing because my assumption was wrong. That's testing.

The notebook doesn't need to preserve every thought forever. It needs to help me think while the investigation is happening. Automation Before Automation. There's a line in the notebook that probably summarizes the whole idea better than anything else: Think first. Test second. Automate when it makes sense. I'm obviously not against automation. Quite the opposite.

But automation becomes much more useful after we understand what behavior matters, what risks we're protecting against and what conditions are worth checking repeatedly.

Before asking "How do we automate this?", somebody still has to ask: "What should we test?" That's the space I wanted the QA Notebook to live in. Not instead of Jira. Not instead of Playwright. Not instead of AI. Just next to the keyboard. With a pen. And preferably a tester who keeps asking one more question.

QA Notebook — Think. Test. Question. Write it down.

by Liudas Jankauskas
https://www.amazon.com/QA-Notebook-Liudas-Jankauskas/dp/B0HH6MNG4Z

API Testing Rule #3: Response Codes Are Part of the Functionality

Liudas — Thu, 17 Sep 2026 05:12:27 +0000

An API does not communicate only through its response body. The HTTP status code is also part of its contract.

A successful request should not return the same status code as an authentication failure, invalid input, a missing resource, or an unsupported HTTP method. Clients, monitoring tools, and other services rely on these distinctions.

For example:

201 Created for a successfully created resource
400 Bad Request for invalid input
401 Unauthorized for missing or invalid authentication
403 Forbidden for insufficient permissions
404 Not Found for an unavailable resource
405 Method Not Allowed for an unsupported method
429 Too Many Requests when rate limits are exceeded
500 Internal Server Error only for unexpected server failures
Incorrect response codes can hide bugs, confuse API consumers, and expose information about protected resources.

Response code testing should cover both successful and unsuccessful scenarios. An API that returns the wrong status code is not behaving correctly, even if the response body looks reasonable.

Rentgen helps explore these cases automatically from a working cURL request, including invalid input, authentication failures, unsupported methods, and unexpected responses.

HTTP status codes are not decoration. They are functionality.

Full white paper:
https://qaontime.com/research/the-power-of-ten-rules-for-testing-http-apis.html