Forem: Liudas

New Rentgen Release v1.20.0 🚀

Liudas — Mon, 06 Apr 2026 17:23:51 +0000

Release v1.20.0 🚀

👉 Project export / import (this is the main one)
No accounts. No cloud. No data leaving your machine.
Export your project → get a file → put it anywhere: Dropbox, GitHub or any shared folder. Your team (5, 100 or 10 000 people) just takes it and uses it. At 0 cost. And No sync back to server. No logins. No vendor lock-in. No data exposure. Just a file. Full control.

👉 New test: invalid token. We take your Authorization and break it.
Expected: 401
Reality: often not.

👉 Response time. Now visible per request and per test. No extra tools. No guessing.

Paste a request. See what breaks. Automation before automation.

New release Rentgen.io

Good breakdown and read on medium of a problem most teams don’t even realize they have

Liudas — Wed, 01 Apr 2026 14:26:20 +0000

APIs pass tests. CI is green. Everything looks fine. But production still breaks — not because of complex bugs, but because of simple things nobody tested.
👉 missing auth
👉 invalid inputs
👉 unexpected formats
👉 edge cases that never made it into tests

The article explains this gap really well — between “what we test” and “what actually breaks”. That’s exactly where Rentgen sits:
👉 not replacing tests
👉 but showing what you didn’t think to test

Paste one request → see what breaks.
Worth a read 👇
https://medium.com/@berastis/your-api-passed-all-tests-rentgen-found-47-bugs-anyway-df0be5e1d0f3

This meme is so far from reality

Liudas — Thu, 19 Mar 2026 09:09:55 +0000

I saw this meme and honestly it’s so far from reality.

We keep talking about shift-left, testing earlier, bringing QA into development and then we share memes like this, implying API testing somehow doesn’t make sense. First of all, API itself can be the product. Second: even if it’s not - API always needs to be tested separately. Different bugs. Different rules. Different risks. You don’t test API like a user clicks a UI.

You test: success paths, validation errors, auth mechanisms, rate limiting, performance, edge cases and many others.

Most of which you can’t even properly test through the UI. That’s the whole point.

And this is exactly why we built Rentgen.io

To take care of these boring, but critical checks instantly - without setup, without writing tests, without pretending clicking buttons will somehow cover your backend.

Automation before automation.

AI and Rentgen are best friends

Liudas — Mon, 16 Mar 2026 16:53:39 +0000

AI generates code and APIs faster than humans can realistically validate them.

More APIs → more drift → more regressions. That’s exactly why Rentgen exists.

Rentgen helps teams quickly understand how their APIs behave under real-world input: before writing tests, before CI, before production incidents.
As AI accelerates software creation, the need for fast API diagnostics only grows.

👉 rentgen.io

Automation before automation. Find API bugs when you have no tests.

ps.: Rentgen CLI soon. Rentgen CI/CD tests when you have no CI/CD tests.

Automation Before Automation: Finding API Bugs When You Have Zero Tests

Liudas — Thu, 26 Feb 2026 13:45:23 +0000

“Regression testing without tests” sounds like marketing nonsense. If someone told me that a year ago, I’d probably roll my eyes and move on. So let’s unpack what this actually means, using a real workflow.

Rentgen introduced what I call regression out of the box. You don’t need a predefined test suite. You don’t need an OpenAPI file. You don’t need CI configured. You don’t even need existing assertions. All you need is one working request.

The idea is conceptually similar to how Open Diffy at Twitter compared responses across environments. But here you don’t need traffic mirroring or complex infrastructure. You import a real cURL request — ideally something you already know works in production — and run it in Rentgen.

If the request is successful, you map the fields. That means you tell Rentgen what each field represents: an ID, a timestamp, a numeric value, an enum, something dynamic, something stable. This step is critical because it gives context to the engine. After that, you press “Generate and Run”.

At this point, Rentgen automatically generates dozens — sometimes hundreds — of structured tests from that single request. It mutates inputs, checks structural consistency, validates error handling, and evaluates response behavior. You didn’t write a single test case manually. There’s no collection to maintain. No assertion scripts.

When the run finishes, you press “Select for Compare”.

Now you switch the environment. For example, from PROD to TEST.

You send the exact same request again, map the fields again (because different environments may return slightly different values), and press “Generate and Run” once more.

After the second run is complete, you click “Compare with Selected”.

This is where things get interesting.

If everything behaves consistently, you get a clean green result.

But if something changed — and it shouldn’t have — Rentgen highlights it clearly. Not as raw JSON noise. Not as a giant diff dump. It shows what changed, where it changed, and why it might be a bug.

Traditional automated regression requires predefined expectations. You have to decide up front what is correct. But in real life, especially early in a project or during migration, you often don’t have that luxury. You just want to know: did something drift between environments? Did the new deployment introduce structural inconsistency? Did error handling degrade?

That’s what I mean by Automation Before Automation.

This does not replace your test suite. It doesn’t compete with Postman, Playwright, or your CI pipeline. It sits one layer earlier. It answers a diagnostic question before you invest time in writing and maintaining formal tests.

You can still inspect full drift if you want. There’s a toggle to see all differences, including raw structural changes. Nothing is hidden. But by default, Rentgen filters noise and surfaces potential issues that matter.

The important part is this: you can detect API bugs even when you have zero tests written.

No framework setup. No CI integration. No collection maintenance.

Just one real request.

That’s regression out of the box.

Find out more: https://rentgen.io

546 Tests. 0 Failures. API Still Burning🔥

Liudas — Thu, 26 Feb 2026 05:12:38 +0000

Everyone loves a green test summary.

546 tests.
0 failures.
100% successful.

Meanwhile, the API is quietly burning in the background.This is the part nobody likes to admit.

You can have:

perfect automation coverage
beautiful dashboards
CI pipelines glowing green

And still ship broken API behavior.

Because business logic can pass.
Happy paths can pass.
Regression suites can pass.

And yet:

wrong status codes
broken error handling
missing headers
inconsistent contracts
silent structural drift

Automation is doing exactly what you told it to do. The problem is — you didn’t tell it enough.

This is why “automation before automation” matters.

Before writing 500 tests…
Before building another collection…
Before maintaining another brittle suite…

Ask one question: What actually happens if we stress this endpoint from the outside?

When you run diagnostics before writing tests, you often find things you didn’t even think to test.

That’s not anti-automation. That’s making automation meaningful.

Rentgen is built for that first layer.

Find API bugs when you have no tests.
Find blind spots before your pipeline goes green.
Find structural problems before they become production incidents.

Automation is great.

But sometimes, automation before automation shows you more than you expected.

And that’s where real API quality starts.

I Spent Two Minutes Testing Amazon’s API. It Was Enough.

Liudas — Tue, 24 Feb 2026 18:27:26 +0000

There’s something oddly comforting about large tech companies. You assume that somewhere, deep in the labyrinth of their infrastructure, there are teams of very serious engineers making sure everything behaves exactly as it should.

So when I decided to test one Amazon endpoint, I picked the most boring one I could find.

Not payments. Not checkout. Not anything involving money.

Just this:

PUT /custom/profilepickerserviceapicontracts/marketplaces/{id}/members/{memberId}

All it does is update a child profile name. You send "name": "Kids3", and life goes on. Or at least, that’s the theory.

I captured the real browser request, pasted it into Rentgen, pressed run, and went to make coffee. Two minutes later I had a certificate score: 16 out of 100.

Sixteen.

Now, this wasn’t a penetration test. I didn’t try to break the system. I didn’t throw SQL injections at it. I didn’t spin up some exotic fuzzing setup.

I just asked very boring questions.

What happens if authentication is missing?
Apparently not 401 — but 400. With a generic “Sorry, we are experiencing issues right now.” Which is comforting, in the same way that a smoke alarm yelling “Something is wrong somewhere” is comforting.

What happens if you use an unsupported HTTP method?
You get 403. As if the method exists but you’re not important enough to use it.

What happens if you uppercase the path?
You get HTML. Yes. A full CloudFront “Website Temporarily Unavailable” page — from a JSON API. Because apparently, sometimes your structured contract just takes the day off.

And then the fun one: send a 10MB payload. Not malicious. Just large. Instead of a clean 413 Payload Too Large, the request travels deep enough into the stack to come back confused with a 404.

All of this. From renaming a child profile.

This isn’t about “Amazon is broken.” It’s about what happens when systems grow faster than their contract discipline. Status codes drift. Edge layers leak. Validation happens too late.

The scary part isn’t that these things exist.

It’s how quickly they surface when you look.

Full breakdown here:
https://rentgen.io/api-stories/amazon-profile-update-api-testing-case-study.html

Automation before automation. Find API bugs when you have no tests.

Your API “Won’t Grow”? That’s How Outages Are Born.

Liudas — Sun, 22 Feb 2026 05:32:42 +0000

There’s a dangerous sentence in API design: “Don’t worry, it won’t be that many records.”

That’s how unpaginated collection endpoints get shipped.

GET /users
Returns a JSON array.
No limit? No page? No cursor?

Works perfectly.

Until production data grows.

Then latency grows. Memory grows. Payload size grows.
And suddenly your “simple” endpoint becomes a scaling liability.

Rentgen flags this pattern automatically:
• GET endpoint
• JSON array response
• No pagination or limit parameters

It’s not a failure.
It’s a warning about future technical debt.

Because unbounded lists don’t break immediately.
They break when your product succeeds.

Full breakdown here: https://rentgen.io/api-stories/array-list-without-pagination.html

Fix it while it’s boring.

Testing Proton Pass API Without Knowing Its Architecture

Liudas — Thu, 19 Feb 2026 15:42:09 +0000

I took a real Proton Pass API request straight from the browser and ran it through Rentgen.

No architecture knowledge. No configs. No scripts. Just import cURL → generate tests → wait a minute.

The result? A 46% structural score and several interesting protocol-level signals — including large payload handling and auth gate sequencing.

This isn’t a “security drama” post. Proton builds serious products. But even mature APIs can benefit from deterministic hygiene checks before automation ever starts.

Full breakdown here:https://rentgen.io/api-stories/protonpass-api-under-rentgen.html

Your API Returns 400 for Huge Payloads? Congratulations. You Just Built a Polite DoS Gateway

Liudas — Thu, 19 Feb 2026 03:00:40 +0000

There’s a special kind of bug that looks completely harmless. You send a massive request body. The API calmly replies:

400 Bad Request.

Nothing crashes. No alarms. Everyone shrugs.

And that’s exactly the problem.

When an oversized payload hits your API, the only correct response is 413 Payload Too Large. HTTP already solved this years ago. If you return 400, you’re basically saying: “Something is wrong with your data,” instead of: “This request is too big and I refuse to process it.”

But here’s the uncomfortable part.

By the time you return 400, the server may have already:
• Allocated memory
• Parsed JSON
• Spent CPU cycles
• Tied up worker threads

Multiply that by concurrent requests and suddenly you’re not debugging a validation issue. You’re watching your service politely walk into a denial-of-service scenario.

This is why I added a Large Payload Test into Rentgen.

It takes a valid request and inflates only one thing: the body size. No broken JSON. No invalid headers. Just more data than your API should reasonably accept. The expected result is simple: 413. Immediately. At the boundary.

Anything else means your server is doing work it should never have started.

And this isn’t theoretical. The exact issue was detected in the ChatGPT API. Oversized payloads were being processed incorrectly. It was reported. It was fixed within a day. That response speed tells you everything about how serious this class of bug actually is.

The reason it survives in most systems is beautifully human:
• “Clients won’t send that much data.”
• “We validate input anyway.”
• “This endpoint isn’t public.”

Attackers love assumptions like that.

The fix is boring — which is precisely why it works:
Define strict payload limits. Enforce them at the edge. Return 413 consistently. Document it.

No drama. No heroics. Just discipline.

APIs don’t fall over only because of exotic exploits. Sometimes they fall over because they were too polite to say: “This payload is too large.”

If your API returns 413 consistently, you’re not being strict. You’re being responsible.

Full story and technical breakdown here: https://rentgen.io/api-stories/large-payload-handling.html

Your API Doesn’t Have a Bug. It Just Hates Capital Letters.

Liudas — Wed, 18 Feb 2026 02:38:31 +0000

You know what’s beautiful?

Spending three hours debugging auth headers, payload validation, and middleware…
Only to discover someone typed /V1/users instead of /v1/users.

One capital letter. Half a day gone. Brilliant.

Here’s the problem.

Unlike domains, URL paths are usually case-sensitive.
So /v1 and /V1 are technically different resources. That’s fine.

What’s not fine is when your API responds with:
• 400 Bad Request
• 403 Forbidden
• 500 Internal Server Error

None of those say the real thing: “This resource does not exist.”

Instead, they send developers down the rabbit hole of:
• comparing headers
• rechecking tokens
• blaming payload
• questioning infrastructure
• arguing in Slack

All because of one uppercase letter.

What Rentgen does

Rentgen takes a valid request and mutates only one thing:
It converts the entire path to uppercase. That’s it.

And then it checks:
• If paths are strict → return 404 Not Found
• If paths are normalized → return 2xx
• Anything else → misleading behavior

Simple. Deterministic. Brutal.

This isn’t some exotic security flaw. It’s worse. It’s a time vampire.

It won’t crash production.
It won’t trigger alerts.
It will just quietly burn engineering hours while everyone swears “it works on my machine”.

APIs don’t fail only on complex edge cases. Sometimes they fail because Caps Lock was on.

If your API handles uppercase paths predictably, you eliminate an entire class of pointless debugging.

And that’s worth more than it sounds.

Full article here: https://rentgen.io/api-stories/uppercase-path-handling.html

Your API Breaks Because Someone Used Caps Lock

Liudas — Tue, 17 Feb 2026 02:55:12 +0000

Yes. This actually happens.

Someone calls your API as API.EXAMPLE.COM instead of api.example.com…
And your backend responds with 404. Or 500. Or something equally embarrassing.

Congratulations — your API is sensitive to keyboard mood.

Rentgen runs a simple mutation: it takes the exact same request and uppercases only the domain. Nothing else changes. The expected behavior? Exactly the same 2xx response.

If it fails, that’s not “edge case”. That’s infrastructure smell.

DNS doesn’t care about casing. Browsers don’t care. Most tooling doesn’t care. If your API does — somewhere in your stack you’re matching the Host header as raw text instead of treating it like the identifier it is.

The worst part?
When this bug hits, nobody suspects it. Teams debug payloads, auth, headers, routing… while the root cause is literally Caps Lock.

In this run: 🟢 Pass (200 OK).
Good. That’s how it should behave.

But when it fails in real systems, it’s usually because of sloppy reverse proxy rules, case-sensitive host matching, or dev configs that were “temporary” three years ago.

Your API should not break because someone typed in uppercase.

Full breakdown and real-world cases here: https://rentgen.io/api-stories/uppercase-domain-handling.html