People occasionally ask me whether Rentgen is trying to replace Swagger. The short answer is no.
In fact, I think Swagger is one of the best things that happened to API development. Without it, many modern APIs would be painful to build and even harder to consume. OpenAPI gives teams a common language. Developers know what they’re building, frontend developers know what to expect, and third parties know how to integrate with the API.
The problem starts when we assume that because the specification is correct, the implementation must also be correct. Those are two completely different things.
Swagger describes how the API should behave. The backend is still just code written by humans, and humans make mistakes. A required field might accidentally become optional. Validation might stop working after a refactoring. Invalid JSON might return a 500 instead of a 400. A payload that should be rejected might quietly pass through. None of that makes Swagger bad. It simply isn’t trying to solve that problem.
This is exactly why I built Rentgen. Rentgen doesn’t read your OpenAPI specification. It doesn’t try to understand your intentions. It starts with a real request, usually copied as cURL from Swagger UI, browser DevTools, Postman, or logs, and asks a different question: “What happens if this request isn’t perfect?”
Instead of sending only the happy path, it starts changing things. Fields disappear. Values become too long. Types become invalid. Payloads become malformed. Authentication changes. Headers disappear. Then it watches how the backend responds. Sometimes nothing interesting happens. Sometimes you discover that the API happily accepts data it shouldn’t. Sometimes you discover that one missing quote crashes an endpoint with a 500.
Those are not theoretical problems. They’re exactly the kind of bugs I kept finding while testing production systems.
Over the last twenty years, I’ve noticed something else. Most teams start automation surprisingly late in the process. They write Postman collections, Playwright tests, REST Assured suites, or CI pipelines before they’ve really explored how the API behaves outside the documented scenario.
That’s the idea behind Automation Before Automation (ABA). Before investing hours or days into automated tests, spend a few minutes understanding the real behaviour of the API. Find the obvious validation problems. Fix them. Then automate.
The automation you build afterwards is usually better because it’s based on reality instead of assumptions.
For me, Swagger and Rentgen fit naturally into the same workflow. Swagger helps me understand the contract. I copy a request from Swagger UI, paste it into Rentgen, and let it explore the implementation. Only after that do I start writing long-term automated tests.
I don’t see these tools competing with each other. Swagger answers, “What should this API do?” Rentgen answers, “What does this API actually do?”
Those are different questions, and both deserve an answer.
Top comments (0)