Hi everyone,
one small thing to announce before we head off into the long weekend.
Specifically we’ve made a minor security-conscious update to how the OpenCage Geocoding API handles the optional add_request parameter.
When add_request is set to 1, the API includes the original request parameters in the response, a useful feature for debugging. One of those parameters is the required API key.
We now return only the first 6 characters of your key in the response, with the remainder replaced by asterisks (e.g. ab1234**************************).
For a full example of the JSON response:
{
"documentation" : "https://opencagedata.com/api",
"licenses" : [
{
"name" : "see attribution guide",
"url" : "https://opencagedata.com/credits"
}
],
"request" : {
"abbrv" : 0,
"add_request" : 1,
"address_only" : 0,
"format" : "json",
"key" : "ab1234**************************",
"language" : "en",
"limit" : 10,
"min_confidence" : 0,
"no_annotations" : 0,
"no_dedupe" : 0,
"no_record" : 0,
"pretty" : 1,
"proximity" : "",
"query" : "52.5432379, 13.4142133",
"roadinfo" : 0,
"version" : "v1"
},
"results" : [
{
...
Why the change?
API responses are often written to log files, and it’s easy for sensitive values to end up somewhere they shouldn’t be. By masking most of your key, we reduce the risk of it being inadvertently exposed through application logs or debugging output.
What do you need to do?
For the vast majority of developers, nothing. This change is purely cosmetic, your actual key is unchanged and your requests will continue to work exactly as before.
Unrelated to this change, you can always generate a new key at any time. Subscription customers can have multiple keys, free-trial and one-time plan customers are limited to a single active key.
We also encourage you to review our guidance on how to protect your API key and our broader security policies.
As always, we welcome you feedback.
Happy geocoding,
Ed