403 error from Rebrandly using fetch()

I’m on this exercise, and I can’t figure out why I’m getting 403 errors from Rebrandly when I try and submit my POST request. The previous exercises worked fine.

I’ve been back over each step of the code, which in this exercise is pretty prescriptive “write this line here” stuff. I’ve also checked my API key is correct (it was) and then tried generating a new one, which didn’t help. I get no errors to console until I try and submit the request, at which point it returns HTTP status code 403.

Here’s the full response object I get back, which I got by logging it to the Chrome devtools JavaScript console:

Response

  1. body: (...)
  2. bodyUsed: false
  3. headers: Headers {}
  4. ok: false
  5. redirected: false
  6. status: 403
  7. statusText: ""
  8. type: "cors"
  9. url: "https://api.rebrandly.com/v1/links"
  10. __proto__: Response

There’s nothing in the body of the response. I can expand the headers object, but that also contains nothing except the methods it inherited from the Headers prototype.

I looked up CORS and figured out that it’s Cross-Origin Resource Sharing, which tells me a little, but seems a bit above my paygrade given that I just learned about the Fetch API. I also found this medium article which mentions that it’s important to include the Content-Type header and specify “application/json” - but we’re already including that. I thought for a moment that maybe it’s because the lesson specifies Content-type rather than Content-Type, but that didn’t help, and Stack Overflow confirms that HTTP headers are case insensitive.

Any other clues on what might be causing the request to fail for CORS or other reasons?

Well, typically, after spending half an hour headscratching and trying to fix this, I moved on to the next lesson, which helpfully tells you:

Put in any URL in the text field, and then click the shorten button on the webpage. Make sure you include the entire link, including ‘http://‘ or ‘https://‘.

And indeed, links beginning http:// or https:// do generate a valid response. So I guess that’s what was making it return an error, but I’m still a little unclear on exactly why.