Let’s clear this up immediately: Rentgen is not here to replace Postman. And pretending otherwise would be dishonest.
If you live in Postman — writing scripts, crafting assertions, maintaining collections for CI, debugging runners at 1 a.m. — then Rentgen is not competing with that. Rentgen exists before all of that.
The part of API testing everyone does — but nobody talks about
Most developers use Postman as an API client. Not as a testing framework. They import a cURL, send a request, see a response, and move on.
No assertions. No edge cases. No negative testing. Not because they’re lazy — but because the first step is usually made unnecessarily heavy.
So APIs get handed over with the classic line: “I tested it. It works.” Testers hear that sentence every week. And they already know what comes next.
What Rentgen is
Rentgen is a local-only API hygiene scanner built for one thing: to stress-test your assumptions before you waste time polishing a false sense of “done”.
You paste a single cURL. You send the request. Then you click Generate & Run Tests. That’s it.
Rentgen expands one request into a messy, realistic set of tests — the exact kind of inputs real systems see in production when humans (or integrations) do human things.
What Rentgen tests automatically
Not “happy path theatre”. Real hygiene. The boring, predictable, expensive stuff people skip until it hits prod.
- Missing required fields and unexpected nulls
- Wrong data types (string instead of number, object instead of array, etc.)
- Boundary values that should be rejected cleanly
- Enum variations (wrong casing, invalid values, random junk)
- Trimming and whitespace issues (leading/trailing spaces, empty strings)
- Malformed payloads that should never crash a backend
- Status codes that look “fine” until you read what they actually mean
No assertions? Correct.
Rentgen does not ask you to write assertions. And that’s intentional. Because Rentgen is not trying to prove your API is correct. It’s trying to expose how it behaves when inputs are imperfect.
The model is brutally simple: 2xx–3xx means “acceptable behaviour”, 4xx means “your API handled bad input without panicking”, and everything else is a problem worth looking at.
You’re not building a test suite here. You’re running a reality check.
Collections without ceremony
You group requests into collections. Your work stays saved. When you want to run them, you click Play.
No test runners. No setup rituals. No pre-scripts. No post-scripts. No “wait, where is that environment variable defined?” nonsense. Just run the collection and see what breaks.
Environments that don’t get in the way
Rentgen supports environments, and it does it in a way that makes sense in the real world. Different environments have a color, so you instantly know where you are.
You can save response values into environments once, automatically, persistently. Next time you run the same collection, Rentgen knows how to reconnect the data — without scripts, without copy-paste, without pretending this is normal.
Why this is not competing with Postman
Postman is great at scripted testing, complex workflows, and detailed assertions. If that’s your job — keep using it.
Rentgen is for the moment before that — when a developer wants to answer one honest question: “Did we miss something obvious before handing this API to QA?”
Run Rentgen first. Fix the stupid stuff. Then let testers do their job properly. Developers look more professional. Testers waste less time on low-hanging bugs. Everyone wins.
Built by a tester. Used by developers.
Rentgen wasn’t built to chase trends. No AI agents. No cloud sync. No telemetry. No accounts.
It was built by someone who has tested APIs long enough to know the truth: most bugs come from boring input mistakes everyone thinks are “impossible”.
If you already use Postman — great. Keep using it. Just run Rentgen before you say “it works”.
Because “it works” usually means “I tried the happy path once”. And production doesn’t care about your happy path.