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.

Background

Table of Contents

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.

Problem

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

https://errors.edgesuite.net/9.5a6a645f.1715718915.495dc950

That was… Unexpected. But what gives?

Reason

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.

Solution

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 edgesuite.net domain belongs to.

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

Author
Recent Posts

Antti K. Koskela

Developer / Speaker / Consultant at Koskila / Precio Fishbone / Norppandalotti Software Co / Alter - Experience Ideas Ltd

Antti Koskela is a proud digital native nomadic millennial full stack developer (is that enough funny buzzwords? That's definitely enough funny buzzwords!), who works as Solutions Architect for Precio Fishbone, building delightful Digital Workplaces.

He's been a developer from 2004 (starting with PHP and Java), and he's been working on .NET projects, Azure, Office 365, SharePoint and a lot of other stuff. He's also Microsoft MVP for Azure.

This is his personal professional (e.g. professional, but definitely personal) blog.

Latest posts by Antti K. Koskela (see all)