I’m developing an EV navigation app and for some weeks I successfully used the V3 POI endpoint entering an encoded polyline returned from google directions API. Today I noticed that it is returning me now seemingly random charging locations (I’m located in Hungary but for cities here no matter which polyline I post I get back charging stations from Spain, Morocco, Italy…) In some cases when I tested with Android emulator I even got back a 503 - API requests by robots temporarly disabled.
Could anybody update me whether some conditions changed or new terms and conditions are applied?
Hi Zoltan, sorry for the delay in replying, can you provide an example encoded polyline to test with?
Yes, our backend API was recently ported from .net to .net core which required some changes to the spatial libraries we were using so there could be a bug.
I also noticed by the the way that sometimes I also got 503 - robots are temporarly disabled (of course I’m using the API within an app, but no misuse or heavy burst like calls just one when the user enters the destination however I still sometimes got that)
Thanks, I’ll investigate the polyline issue and let you know. Regarding the 503 error, our API is behind CloudFlare which does some traffic management of it’s own that we can’t really influence but there is also some stuff in place to block certain user agents - typically where they have attempted to crawl the API results by brute force.
People sometimes search repeatedly across a grid using multiple servers/clients in an attempt to rapidly download all the data where they just needed to set maxresults and actually download all the data in one go.
To avoid being blocked because of a generic user agent, set your http user agent to something custom that identifies your app. If you query repeatedly make sure your call rate is throttled and de-duplicated so that it can’t make repeated exact duplicate calls multiple times per minute.
In the future we will likely require apps to register api keys/tokens so that we know what/who they are as it only takes one user to spoil it for everyone
That should be fixed for you now. During the port to .net core the process whereby we expand a polyline into a search polygon had broken. Investigating/fixing this was useful as it also led to creating some new integrations tests and some search optimisation.
Behind the scenes we have a MongoDB based caching layer which is normally the layer that responds to queries, if the cache is out of date our SQL layer may respond instead and each layer has their own way to perform the spatial queries (such as finding points in a search polygon).
