This is not a company blog. We don’t publish feature announcements, roadmaps, or “10 tips to improve your API”. Real-world API behaviour, exposed. Not tutorials. Not mock data. Not perfect examples. Just real APIs doing unexpected things under pressure.
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.
Read story →We pointed Rentgen at a real ChatGPT telemetry endpoint and triggered 500 Internal Server Errors using nothing but malformed input. No fuzzing, no guessing — just a copied cURL and one mutated field.
Read story →Boundary value analysis is one of the most effective testing techniques — and one of the easiest to forget. Rentgen makes it impossible to skip by generating boundary tests automatically from your API input definitions.
Read story →Trimming is a small check that causes big integration failures when ignored. Rentgen detects whether your API normalizes string input or silently accepts leading and trailing whitespace that later breaks uniqueness and client assumptions.
Read story →Rentgen includes a lightweight load test built directly into API testing. With just a few parallel requests, it reveals performance degradation long before real traffic hits production.
Read story →Rentgen flags GET endpoints that return JSON arrays without pagination or limits. It’s not a functional bug yet — but it’s a classic design risk that quietly turns into performance problems and client failures as data grows.
Read story →
Rentgen detects oversized JSON responses automatically.
If a single response exceeds 100 KB, it’s a clear sign of overfetching,
missing pagination, or leaking internal data — problems that usually go unnoticed until it’s too late.
Rentgen calculates how much of the total response time is pure network latency. When ping consumes a large share of the response, backend optimization won’t help — the problem is distance, routing, or too many hops.
Read story →
Rentgen treats ping as a baseline signal, not a curiosity.
If network latency exceeds 100 ms in a nearby environment,
response time metrics become unreliable — and performance analysis starts from the wrong place.
Rentgen doesn’t run load tests.
It sends real requests one by one — and still measures how your API responds.
If the median response time exceeds 500 ms without any load,
something is already wrong.
400 quietly enables denial of service
Oversized requests should be rejected immediately.
If your API responds with 400 Bad Request instead of a clear
413 Payload Too Large, it may already be parsing and allocating
resources — opening the door to trivial DoS attacks.
/V1 wastes half your day
URL paths are usually case-sensitive.
If your API responds with 400 or 500 instead of a clear 404,
developers end up debugging payloads and auth —
when the real problem is just one uppercase letter.
Uppercase domains are rare but real.
When APIs fail on API.EXAMPLE.COM or LOCALHOST,
the issue is usually hidden in proxies, routing rules, or local dev setups —
and almost never covered by tests.
Echoing user input in API error responses feels useful during development, but it creates long-term risk. One copied error message, one careless UI render — and your validation logic becomes a delivery mechanism.
Read story →
When non-existent endpoints return 200 OK,
APIs lie to their clients and dashboards lie to engineers.
Errors disappear from monitoring,
while users and partners keep hitting URLs that should never exist.
Overly permissive or overly restrictive CORS settings are rarely intentional. They usually come from copy-paste defaults and forgotten decisions, leaving teams with APIs that work in curl but fail in browsers and integrations that were never meant to be blocked.
Read story →
When authentication is missing, the only honest response is 401 Unauthorized.
Returning 403 Forbidden or 400 Bad Request misleads clients,
turns simple mistakes into long debugging sessions,
and makes developers question everything except the real problem.
Returning 200 OK for an unsupported HTTP method breaks trust.
Instead of a clear signal like 405 Method Not Allowed,
clients get silence — and engineers waste time debugging payloads
when the real problem is simply the wrong method.
OPTIONS isn’t “extra”. It’s how clients and browsers ask what an endpoint allows.
If your API answers a valid OPTIONS request with 400 Bad Request,
you risk broken CORS preflights, confusing client behavior, and a REST API that doesn’t speak HTTP properly.
HTTPS doesn’t stop browsers, proxies, or devices from caching responses. Without explicit Cache-Control rules, private API data can quietly persist after logout, across sessions, or even across users — turning normal behavior into a data exposure risk.
Read story →APIs assume clients respect Content-Type. Browsers don’t always agree. Without X-Content-Type-Options: nosniff, a response meant to be data can be reinterpreted as executable content — quietly turning a harmless API into an attack surface.
Read story →HTTPS alone doesn’t guarantee safety. Without HSTS, clients may still accept HTTP during redirects or first contact. It’s not a breaking issue — but it quietly weakens transport security in exactly the places attackers like.
Read story →Clickjacking isn’t about broken APIs or crashing systems. It’s about valid actions executed through invisible frames. Missing X-Frame-Options or CSP frame-ancestors doesn’t look dangerous — until a real user clicks “Approve” on a page they can’t even see.
Read story →Sometimes security fails not because things are hard, but because they are boring. Exposing your server version in response headers is one of those tiny details that quietly helps attackers — and quietly slips through reviews.
Read story →Jira is one of the most trusted developer tools in the industry. We took a real ticket creation request, ran it through Rentgen, and looked at how the API behaves under invalid input, edge cases, and load — no theory, just reality.
Read story →REST clients help you send requests. API testing tools help you understand whether your API is actually good. Most people confuse these two.
Read story →