Postman - the destroyer of APIs

Suddenly receiving “The requested URL “[no URL]”, is invalid.” in Postman?

2 min read.

This article explains how to get around a sudden issue, where Postman suddenly starts showing you a nondescript and slightly misleading error about a missing URL in your request when you haven’t removed any parameters and the request just worked.

But don’t let me get ahead of myself.


So me and my team have had the questionable honor and privilege to build some integrations to SuccessFactors – a SAP product – lately. That means we’ve been reading through their developer documentation and playing with their APIs a lot in recent times.

And boy, is it refreshing to work with a real, honest-to-God Corporation again! They’re definitely less hostile than Workday and its ilk, but still: documentation is outdated (but it IS hundreds of pages long for any API), there are 15 methods that sound like they do the same thing, but they work entirely differently, everything is so customized-per-customer that documentation would be useless anyway and no common standards are ever honored.

Makes working with Microsoft feel like you’re dealing with a nimble, modern startup – they may break things, but they don’t live in the 90s and (sometimes) listen to your feedback.


I had a saved request in Postman, that I used to fetch a new access token. So far, so good.

Nothing too out of the ordinary there. This request worked nicely for a while, until one day – it threw this:

And below in copy-pasteable format:

Invalid URL
The requested URL "[no URL]", is invalid.
Reference #9.5a6a645f.1715718915.495dc950

That was… Unexpected. But what gives?


Oh well. Apparently this particular issue wasn’t caused by SAP (many of my headaches are), but rather by Postman messing with my saved requests for whatever reason.

See, the error DOES mention “Invalid URL”. But the request itself was correct, and while SAP does want a few parameters for that particular API (for authentication), I was quite certain I had them all in place.

And the request had just worked a couple of days earlier. So something else was amiss.

On closer inspection, I found the reason for my issues. The culprit was a missing “Host” header in the request.


In my case, the solution was a bit unintuitive, but incredibly easy to fix. Just add the header back.

You won’t even necessarily always need most of the headers, but “Content-Type”, “Content-Length” and “Host” are required by, for example, Akamai – the service domain belongs to.

With the “Host” header enabled, the API started playing nice again.

0 0 votes
Article Rating
Notify of

Inline Feedbacks
View all comments