Without cURL, Rentgen Doesn’t Exist — But cURL Alone Isn’t Enough

I’ve seen this pattern too many times to ignore. You write a clean cURL request, hit enter, get a nice 200 back, JSON looks good, and suddenly everyone relaxes like the job is done. cURL is brilliant at that moment. It is simple, direct, brutally honest. You send exactly what you wrote and the server responds. No magic, no abstraction, just raw truth. And that’s exactly why developers trust it. If something works in cURL, you know what was sent. But here’s the uncomfortable part: it only proves that one exact request worked once. Nothing more.

Real APIs don’t live in that perfect scenario. Fields go missing, values change, types break, tokens expire, payloads get messy, and clients behave in ways nobody planned for. And suddenly that clean request doesn’t mean much anymore. You could write dozens of variations by hand in cURL, but let’s be honest, nobody wants to sit there crafting broken payloads all day just to see if something explodes.

This is where I ended up building something on top of that idea. Instead of replacing cURL, just extend it. Take one working request and start asking a better question: what happens when this request stops being perfect? That’s the gap. That moment between “it works” and “it actually survives real input.” Turns out that’s where most of the interesting problems live. Inconsistent validation, weird status codes, backend 500s that should never exist, responses that make debugging unnecessarily painful.

The workflow is simple and it makes more sense than pretending one tool can do everything. Use cURL to get the request right. Then take that exact request and push it a bit. Remove fields, break types, stretch boundaries, mess with payloads. Now you’re not testing one scenario anymore, you’re seeing how the API behaves in reality. And that’s a very different picture.

A lot of teams jump straight from a working request into automation. They build clean test suites around clean scenarios and feel safe. But automation built on assumptions is just a faster way to miss things. If you don’t explore the messy cases first, your tests will simply never cover them.

So no, this is not cURL vs anything. cURL stays exactly where it belongs — as the ground truth. But one request proving it works is only half the story. The other half is figuring out what breaks. And that’s where things actually get interesting.

Full version: https://rentgen.io/api-stories/cURL-and-Rentgen-one-proves-it-works-the-other-proves-what-breaks.html