4 min read

An Introduction To The Google Reverse Geocoding API

An Introduction To The Google Reverse Geocoding API

As part of the ZPET revamp I decided to add some new features, one of which is advanced ‘historical location tracing’ from the locked iDevice. The feature interprets and parses dats from a variety of databases, logs and caches on the iOS Device - I should comment at this functionality is avalible from BOTH BFU (Before First Unlock, Before Pin Entry) and AFU (After First Unlock) state devices.

Parsing this data was a thorough, time-consuming process (to say the least). But it was absolutely worth it, and although I won’t be providing specific details on the data carving and processing side of things(yet), I will be talking about how we can interface with the Reverse Geocoding APIs!

So your first question is probably ‘James, what in the world (excuse the pun) is reverse-geocoding?’ - amazing question right there! I’m not going to throw definitions at you, and i’ll simply explain it as “geographic co-ordinates -> readable address” Here’s an example:

LAT 37.423021 LONG -122.083739

If you can work out an address without using external resources, from just those two values, you’re either a location services engineer situated at Google HQ, or cheating 🔥.

Traditionally, we’d convert addresses to geographical co-ordinates, for the purposes of data collection and processing, among many other real-world uses. This is where reverse-geocoding comes into the scene, and allows us to, you guessed it, reverse this process!

There are caveats to this such as that it becomes difficult to correctly determine an address with only a rough representation of the area. It’ll have you headed in the right direction, though…

What’s an API? How do I get started?

For this process, I like to use the Google Reverse-Geocoding API as it makes everything absolutely painless. Let’s first follow the Google Article instructions, grab our API Key, and we can start to understand each step of the process together.

For those not so familiar with programming, APIs might be a new term (and that’s completely okay). There’s really no in depth knowledge required, and the documentation for an API can be very overwhelming. We often only need to use one little part!

Google has their own instructions for setting up access to this API at https://developers.google.com/maps/documentation/javascript/geocoding (You may need to setup a Google Cloud account - this is a super quick process and completely free).

We’re searching for the Geocoding API, in the Google API Library (This link may work!). Hit enable, following the instructions from that article, and grab your API key. It’ll look something like this:

Now, let’s understand a little about how our request is constructed.

There’s a few parts of the API to understand, and this understanding isn’t necessarily necessary, but as I say, it’s a 2 minute job. Let’s take a look and really understand what we’re doing...

I’m going to split the API Request into parts. Let’s imagine this as a conversation at Subway...

I present, Part 1 - “Hello, I’d like a Subway...


Here we can see we’re placing a request to the Google Geocode API. Nothing special, just an endpoint that handles the request. This address, of course, be different for every API you interface with.

Hello, Part 2! - “...To take away...” (My point here is that we’re going to end up with the Sub, we’ve made that clear, and we’re choosing how it’s presented to us... nothing about the data/ the sub changes, just the presentation)


Part 3 - “...It’s a Veggie Delite sub, please!...” (Here, we’re giving the data/information/input necessary for Subway to produce the precise output/sub you’re looking for!)


And, last but very much not least, Part 4 - “...Oh and here’s my credit card details to take the $!” (This is the credential Google is going to use to measure the amount of processing they’re doing for you, essentially!)


And so, our final request, which will send our geographical co-ordinates to the servers of Google, is just as follows:


Just one last thing before I release article… I just want to note that the API Key is unique to us, and we can construct these requests in an automated fashion to process a TON of data, and when paired with other data such as timestamps, we can start to build a picture of the activity of said device over time!

Wohoo! Congrats 🎉

If everything went to plan, you should now have a well presented, JSON-formatted output from Google detailing the Address, City, Country, etc! Congrats, we did it!

And the last takeaway i’d like to leave with you here is that this process absolutely applies to other APIs you may come into contact with in the future, and your devices are making these requests ALL the time in the background, for a ton of different purposes and processes, such as pulling your warranty status from Apple, as an example!

App owners technically need to implement the ‘api key’ into their app in order for it to work properly, and so technically, the api key could be extracted and used for other purposes, such as skipping capatcha prompts! - I don’t reccomend this!

Anyway, I hope you enjoyed this article and now have a little introduction to how we can start using APIs to, well, reverse-geocode!