Build Different

Putting the TomTom Location History and Geofencing APIs to Work

Mike Baker
Aug 14, 2020 • Last edit on Sep 20, 20228 min read
Laptop displaying web map in dark mode with code

In a previous article, Location History API Service Basics, we delved into the TomTom Location History service. You learned about creating objects and setting them up to be tracked. You saw that, with the Geofencing API, you can create fences of different shapes and, using the Location History API, record the locations of objects over time. Using these two APIs, you can get notifications when items you’re tracking cross the boundary from inside the fence to outside and vice versa.

Today we’ll discuss how these features can be useful in a way you might not have expected. We’ll consider how tracking an item along a route defined by a corridor fence can tell us things about how the route can be improved. To do this, we’ll look at some real-world uses of the Location History API.

We also cover this topic on one of our live coding sessions on Twitch! If you want to watch us show you how, head over to!

Getting Ready to Use the APIs

Let’s review the basics of TomTom API communication. First, however, we'll assume you've already registered for a TomTom Developer account and can set up an application with TomTom to generate API access keys. We'll discuss these later.

Everything we do with an API is through a call to a specific URL called an endpoint. We call the endpoint and pass in the item we want it to use in JSON format. The verb used, POST, GET, PUT, or DELETE, determines what operation will take place.

Let’s imagine we’re an armored car company that picks up and delivers precious cargo between places on the route. Let’s utilize the pieces we’ve learned to get things set up.

The Location History API calls need some data to define objects and geofences. These are defined in a simple JSON format and passed with the API calls. So let's start by defining these items.

We’ll need an object to be tracked, in this case an armored car:

2 "id": "67ef1b09-53bd-4618-9b49-6e17bb139f95",
3 "name": "armored_car_10510",
4 "defaultProject": "a5ef05a2-f1de-4eb0-b6bd-0470bb6e133c",
5 "properties": {}

We'll also define a corridor in which it will travel:

2 "id": "e37eb425-915e-45eb-93e9-bb4f9bd60bed",
3 "name": "corridor_7",
4 "type": "Feature",
5 "geometry": {
6 "type": "LineString",
7 "coordinates": [
8 [
9 -67.000000,
10 45.000000
11 ],
12 [
13 -68.000000,
14 46.000000
15 ],
16 [
17 -69.000000,
18 46.000000
19 ],
20 [
21 -69.000000,
22 47.000000
23 ]
24 ],
25 "radius": 50.0,
26 "shapeType": "Corridor"
27 },
28 "properties": {}

So, we’ve defined one armored car and one corridor. Of course, you can define a number of objects to be tracked and, as we mentioned in the previous article, you can have multiple fences in a project. In the next steps, we'll use these objects with the Location History API.

Using the Location History API

Now we’ll add in the Location History API and take a look at how it can share information with the Geofencing API. Once again, the method of communicating with any API is through the endpoint. The endpoint for the Location History API is:

The first step is to register our key with the API:

6 “secret”: “your_secret”

Remember that Your_API_Key will be replaced with the actual value for your account and project. In the above call, we’re using the register method of the API. You need to have the API key to do that so you edit the key on the TomTom dashboard and add the Location History API:


Then you can supply the key from the dashboard to the register method.


There are some other configuration items you may want to review that can be found on the Configuration service page of the Location History API documentation. When you call the register method with the same key as for the Geofencing, the two will share information— specifically, objects, and location reports.

Recording and Retrieving Positions

When we create an object using the Geofencing API, it’s available from the Location History API registered with the same key.

Next, we need to record the position of the object. This could be done by a device running an app that sends its location based either on a user action in the app or perhaps on a timer.

Next, to record the position of the object, we might assume that a time-dependent or user-initiated location tracking app requires us to report the location. While we won’t be setting up an example app in this article, you might report that location history in your project like this:

7 "type": "Feature",
9 "geometry": {
11 "type": "Point",
13 "coordinates": [
15 4.909934,
17 52.377607,
19 0
21 ]
23 },
25 "object": "67ef1b09-53bd-4618-9b49-6e17bb139f95"

The value of the “object” key provides the ID of the object we specified when creating the object. It could also be the ID that was returned by the API when creating the object, if we didn’t provide one.

There are so many ways to do this and it depends on the device and type of application you’re writing. For more details on sending the position of an object, see the Send position page of the documentation.

Getting an Object's Location History

Now we need to get the location history of an object, meaning the collection of all its positions recorded over a specific time. We obtain the positions that were stored for a given object using the history/positions endpoint of the Location History API. Here’s an example of retrieving the positions for the object ID we’ve been using:


This retrieves the list of positions for the object with ID 67ef1b09-53bd-4618-9b49-6e17bb139f95, starting at 12am on Aug 27th 2019, with no stop time. You can get more details on the Get objects position history page..

Let’s learn more about this by reviewing the result data:

2 "summary": {
3 "name": "armored_car_10510",
4 "id": "67ef1b09-53bd-4618-9b49-6e17bb139f95",
5 "from": "beginning_timestamp",
6 "to": "end_timestamp"
7 },
8 "positions": {
9 "type": "FeatureCollection",
10 "features": [
11 {
12 "timestamp": "timestamp",
13 "type": "Feature",
14 "geometry": {
15 "type": "Point",
16 "coordinates": [
17 longitude,
18 latitude,
19 altitude
20 ]
21 },
22 "estimatedSpeed": speed_value,
23 "estimatedDirection": azimuth
24 }
25 ]
26 },
27 "resultInfo": {
28 "maxResults": max_number_of_results,
29 "pageNumber": page_number,
30 "itemsCount": number_of_results
31 }

As with all calls to the TomTom API, it returns an object. This one has three main properties: summary, positions, and resultInfo.

The summary identifies the target object of the request and the time span you requested in the call.

The resultInfo gives you the maxResults and the itemsCount. The maxResults can be adjusted by including it in the optional parameters in the request. If the itemsCount matches the maxResults, you can use the pageNumber parameter to page through the results.

Finally, we’ll take a look at the positions. You might expect this to be just a collection of X,Y,Z values, but TomTom includes more info. It returns an array of Feature type items (also called a FeatureCollection):

2 "timestamp": "2020-05-30T13:25:51+0000",
3 "type": "Feature",
4 "geometry": {
5 "type": "Point",
6 "coordinates": [
7 19.448183,
8 51.759135,
9 0.00
10 ]
11 },
12 "estimatedSpeed": 16.66,
13 "estimatedDirection": 90.00

All the information you need about an object at a position is here. The “type” is currently always “Feature”. There’s also a timestamp value and the location information, plus estimatedSpeed and estimatedDirection. You don’t actually send these last two data points. TomTom figures them out for you based on the collection of positions it receives from your app (it might look something like the object position reporting API call mentioned earlier).

Location History and Geofences

Now how does this inform us with respect to the fence? We learned in that earlier article that the app can get a notification via the Notifications API when a device leaves the geofenced area. So, you could set up your app to report locations every five minutes while it’s in the fenced area, and then report every minute when it’s outside the area.

Once it returns to the fenced area, it can return to the every-five-minute reporting. Of course, the time values mentioned here are arbitrary—you could report positions every 15 seconds instead.

When a device is within the fenced area, it would typically mean it’s on its regular route. You’d want more detail when the object moves outside the defined area, so you’d have it report more often.

This capability could be handy in a rideshare service scenario. Suppose you have the area you manage divided into sections covered by different vehicles. If a call comes in for an area not covered, one of the vehicles will have to go outside its normal area. If you start getting frequent service calls in an area that’s underserved, you can redesign your sections, using the location history to figure out where the new section should be.

Archiving the History

The Location History API includes a service to archive data associated with locations. You can archive the structure to get the configuration of the objects and settings, and you can archive the position history.

Archiving is a two-step process. You call the structure method to get a token for downloading structure data:


You can call the positions method to get the history of the position data:


Then you use the token returned by either of these to get the URL of the download:


The downloaded file is a ZIP file containing the historical locations in JSON format files, organized by folders representing year, month and days.


Next Steps

The ability to keep track of where objects have been over time, coupled with the ability to use geofencing to define areas of interest, is a powerful combination that can be useful in a variety of scenarios, such as for assessing coverage needs for, say, food delivery routes or rideshare pickup points. What makes this feature even more compelling is that your data is secure within the TomTom environment and won’t leak to other sites or advertisers.

To learn more about Location History, see Location History API Basics and the Location History API developer documentation. Also see Tracking for an overview of all TomTom services related to tracking objects, including Geofencing and Notification.

Get the developer

No marketing fuff. Tech content only.
Thanks for contacting us

We will reach out to you soon.
Blog cards
tomtom tech news