In the past it has been possible to call the OCM API using a fake API key, this was an intermediate cost saving for us because it saved us querying our own database every time to validate if the API key being used is real/enabled or not.
You can get your own API key by signing into https://openchargemap.org and choosing “my apps” from the “my profile” menu. This just gives us someone to contact if there is a problem with your usage of our API or if we need to notify you of significant changes.
If you are currently using a made up API key your API calls will shortly stop working. Note also that if you use an API key belonging to someone else you may receive a permanent ban from your IP - we provide a free service and abuse of the API is not tolerated.
We will shortly be introducing API key checks and may contact groups with very high API usage to discuss options.
Now is also a good time to double check you are passing the API key correctly- previously if you accidentally passed a variable name instead of the actual value e.g. ?key=$openchargemapkey it worked (it was still a unique string).
Also if your API key currently looks like a JWT then you are not using the correct key, OCM API Keys are GUID strings.
Hi Chris - Hope all is well. Just few days back my API Key stopped working. Also today I generated a new key and it still gives the msg: REJECTED_APIKEY_INVALID.
Appreciate if you can provide me what is causing this so it can be addressed and resolved sooner.
It’s either key=<key guid> or using the x-api-key header. A common mistake is to put ?key= because our example might show that, but we assume you know about query urls , that ? only comes at the start and that further arguments are &arg=value
You have included a / in your URL which would be interpreted as a route/path instead of a query string parameter, the api key should also not be ‘quoted’
Your API call should be: https://api.openchargemap.io/v3/poi?key=your-key-abcd123&output=kml&countrycode=CA&latitude={lat}&longitude={lon}&distance=50&maxresults=100
Hi Chris - Thanks for your feedback. I will make the change, test it and get back to you.
One Q - was there any change done on your API side recently for authorization/authentication? If I recall this get request was working until a week back or so.
Also will align to this format for any future requests.
Yes, if you read this topic from top to bottom you will see this is where the planned change was announced and also the message saying it was now live. Your first message in this thread is directly under my comment saying the change was live.
[Note that there was no way for us to notify key owners for improperly supplied keys, because they were improperly supplied, in the worst cases all we could see was things like key=&key=} etc]
Thank you Chris. I have bookmarked this page and also going forward will be more diligent to refer to the updates on this page and on openchargemap community.
Is there any other way to reach you e.g. email, twitter or other contact form other than this page for any future ref,?
I am performing some tests after updating the query to this:
It seems to be working fine. Appreciate if you can also take a pass and suggest if any further optimizations/fine tuning may help?
One issue that I am seeing is that when I change the format to “kml” it gives me this error in the app dev platform I am using.
Error: SyntaxError: Unexpected token ‘<’, “<?xml vers”… is not valid JSONstatus: -1
But when I directly hit in the browser, it download the xml file with the response. Likely I may need to specify the response key path explicitly … in case you have encountered this error from other users, appreciate if you can throw some light.
Again many thanks for your timely help and responsiveness.
I would advise that you use the JSON output as it has much more detailed than the KML output. We do also have GeoJSON output which is useful if importing into a GIS etc. Your development platform is interpreting the KML as as JSON based on the http content type, you may be able to set a content type directly depending on what the platform is.
For optimisations, it depends how you are using the data. For online maps the best thing to do is normally to zoom the users to a specific area then query the API for “bounding box” based on their viewport, rather than distance around a point (your current type of query).
You can also transfer less data by using compact=true which removes reference data objects like ConnectionType and leaves just the reference ID for the ConnectionType (for instance), and verbose=false which removes null fields from the output and removes whitespace formatting.