Receiving HTML response instead of Json

Hi,

I’m relatively new to using Mapillary API. But have been successfully extracting trace data from a bounding box. I have previously had success in the past using the https://tiles.mapillary.com/maps/vtp/mly1_public api to extract sequence ids. However, as of today at about 10:30am (British summer time) I have been receving a html response instead of the expected json response. I still receive status code 200 when making the get request. But my response content looks like this:

b'<!doctype html>\n<html lang="en">\n<head>\n <meta charset="utf-8">\n <meta http-equiv="x-ua-compatible" content="ie=edge">\n <meta name="viewport" content="width=device-width, initial-scale=1">\n <link rel="icon" type="image/x-icon" href="https://www.mapillary.com/app/assets/icon/favicon.ico">\n <title>Mapillary</title>\n <base href="/app/">\n<link rel="stylesheet" href="styles.00c4d08d849eec85.css"><meta property="twitter:card" content="summary_large_image" /><meta property="twitter:site" content="&#064;mapillary" /><meta name="og:title" content="Mapillary" /><meta name="twitter:title" content="Mapillary" /><meta name="description" content="Street-level imagery, powered by collaboration and computer vision." /><meta name="og:description" content="Street-level imagery, powered by collaboration and computer vision." /><meta name="twitter:description" content="Street-level imagery, powered by collaboration and computer vision." /><meta name="og:image" content="https://static.xx.fbcdn.net/rsrc.php/v3/yY/r/OZ6HaDvGves.png" /><meta name="twitter:image" content="https://static.xx.fbcdn.net/rsrc.php/v3/yY/r/OZ6HaDvGves.png" /></head>\n<!-- Google tag (gtag.js) -->\n<script async="" src="https://www.googletagmanager.com/gtag/js?id=G-YWCMMTM18R"></script>\n<script>\n window.dataLayer = window.dataLayer || [];\n function gtag(){dataLayer.push(arguments);}\n gtag(\'js\', new Date());\n</script>\n<body>\n <div class="LoadingBackground">\n <div>\n <div class="LoadingLogo"></div>\n <div class="LoadingSpinner"></div>\n </div>\n </div>\n <main-root></main-root>\n<script src="runtime.a757d37088eb4443.js" type="module"></script><script src="polyfills.edd58b8e96107806.js" type="module"></script><script src="main.451dc0d086e32b0e.js" type="module"></script></body>\n</html>\n'

Does anyone know more about what the issue actually is? I’m a bit lost as to what to try next to fix the issue, as previously this has been working.

Any help would be greatly appreciated!

Hey @pj2g18,

Thanks for reaching out. I couldn’t reproduce it - can you share the specific request that you’re using? Have you added the access token parameter?

Kind regards,
Balys

1 Like

Thanks for responding @abalys.

The request I made was https://tiles.mapillary.com/maps/vtp/mly1_public/2/5/15/10?access_token={}

Where my access token is generated each run, and has worked in the past even earlier this morning. (I will try a different api request to check if the access token is the issue now)

I believe this api request has the html response no matter the parameters I use. I at first thought it was a rate limiting issue but I’ve seen in the docs that I should be receiving status code 4xx not 200.

I’ll test my access token with other api requests and reply again

@abalys For whatever reason, the problem seems to have fixed itself without any changes to the code or parameters.

I couldn’t pinpoint why, but at least it works!

Thanks for getting in touch!

1 Like

Hey - thanks for the response.

Access token can and should be reused :slight_smile:

Let me know if you run into further issues.

Kind regards,
Balys

1 Like

@abalys
Perhaps I spoke to soon… I have now made another attempt to make the same api request, the difference only being that I have a new access token generated (as my program was generating one on startup, which I am now stopping doing and just maintaining the same one). Now a request with any tiles and any zoom produces the same html response,

tiles.mapillary com/maps/vtp/mly1_public/2/14/8045/5439?access_token={}

tiles.mapillary com/maps/vtp/mly1_public/2/14/8115/5161?access_token={}

are examples where that html response with status 200 is reproduced. Though it is happening with every request.

The thing that confuses me the most, is that it seems to be something with the access token as that is the only thing that has changed, however when the error was initially being thrown, it was midway through iterating over a bounding box, and was making the same api gets with the same access token.

I have tested with the getting traffic signals api:

tiles.mapillary com/maps/vtp/mly_map_feature_traffic_sign/2/5/5/5?access_token=

and have the same issue.

It started working when I sent that last response, but has since stopped working again.

The Mapillary API was always quite unstable since the transition to v4. Best is to retry. In my scripts I do up to ten attempts, with increasing sleeps between the attempts. Most of the time this is enough, but not always.

2 Likes

The thing is that I haven’t experienced this problem since before yesterday. And now it is not just failing more often than not, I haven’t seen it succeed in the last 30+ requests I have made. It would be nice to close off that this is a problem on my side at least and that this is a fix that I need to wait for?

Thanks

Hello,

Thanks for reaching out.

I was wondering if you are obtaining the token from here:

Kind regards,
Balys

Hey Balys,

I use the Client id to generate the temporary token which I exchange for the long-term token.

So I first perform:

auth_code = requests.post(https://graph.mapillary.com/token?client_id={})

Next, I use the code from that in:

    body = {"grant_type": "authorization_code", "code": auth_code}
    headers = {"Authorization": "OAuth MLY|{}|{}".format(client_id, client_secret)}
    resp = requests.post(
        "https://graph.mapillary.com/token?client_id={}".format(client_id),
        json=body,
        headers=headers,
    ).json()

The auth_code comes back successfully, but the response to the token exchange is a html Mapillary login page response.

You can use the “Client Token” from Mapillary directly for accessing Mapillary vector tiles without a need for authentication.

1 Like

Would that be using all 3 parts to the client token such as bellow?

https://tiles.mapillary com/maps/vtp/mly1_public/2/14/8022/5155?access_token=MLY|XXX|YYY

Doing this is also failing, however, this morning it was working again, so I ran my program, and got 80% of the way through the UK (previously i had gotten 60%), before it failed (as in html response but with 200 status code). Once it had failed, it was then failing on all tiles, even ones that had been done before. I tried using a second account after this one kept failing, and the second account was also failing. I wonder whether there is some IP rate limiting, that may not be updated to return a 4xx status code instead of 200?

Yes, all three parts together form the token. You can read up on our rate limits here: API Documentation The rate limit for tiles is 50,000 requests per day.

Still not getting a valid response, I don’t think it is rate limiting as it hasn’t worked once today so far.

The fact that sometimes it works and sometimes it doesn’t suggests to me that it is not an issue with my request itself. If it isn’t rate limiting, and requests such as:
https://tiles.mapillary com/maps/vtp/mly1_public/2/14/8022/5155?access_token={}

is working for anyone else, then I’m unsure what could be wrong if I’m getting the status 200 code as well, but just a html response.

Rate limits reset every 24 hours so check back later. I tried fetching the tile URL you provided and it works so I think you’ll be able to access it later.

1 Like

Yep, it’s started to work again, so looks like a rate limiting issue. Do you know how to flag to the developers that there might be a bug in the api that the status code is coming back as 200 when the rate limit is reached, and the error message is not displayed?

thanks for all the assistance!

This forum is good way, like you just did! :slight_smile: We’ll look into the rate limit errors and also improving the rate limits for vector tiles.

1 Like