Better practices for the MyGeotab API

The MyGeotab SDK is a powerful way to integrate other systems with MyGeotab data. Thousands of customers rely on the SDK daily to get everything from trips to exceptions to fuel card data (and more!) into their internal systems.

The APIs used by thousands of customers are the same ones used for MyGeotab in your browser, so it has to be powerful and flexible. But this power and flexibility also allows for abuse, which may impact performance on your system. But never fear, these are some of the common pitfalls and how to avoid them when creating an integration.

See also: Introducing the MyGeotab API Adapter

Hang on to your session

Before a developer makes any call to our API to send or receive data, they first have to authenticate, so we know which server and database to direct the call to.

When a user authenticates (either through the API or signing in to MyGeotab), the server create a “session ID” and returns it. In MyGeotab, this tells your browser to stay signed on. Using the SDK, the server returns a “session token” object, which developers can use to make subsequent calls for the life of the session, which is currently 2 weeks. MyGeotab handles this by popping up a login box. Logging in again re-authenticates against MyGeotab, and renews the session ID stored in the browser.

Authenticating before every API call is not in best practices. This will slow down any third party code because the server it’s calling against now needs to do an additional step. This could mean a time-consuming traversal over all of our servers before the requested data is returned.

The session ID already proves to the server that the caller had authenticated in the past, so it’s quick and easy to use that session token in calls.

For more information, look at the Concepts document, under the heading “Authentication”. Also mentioned in the Concepts document is how to handle session expiry under the heading “Dealing with a database move or credential expiry”.

Some things (almost) never change

A lot of data in MyGeotab changes every minute. Whether it’s the software processing exception rules created by users, or new trips made by vehicles, often there’s new data every few seconds.

Of course, anyone using the SDK has access to this data as soon as it’s created. Dynamic data in MyGeotab includes trips, exceptions, status data, fault data, and more. These datasets are updated every minute or more.

Through our DataFeed interface, it’s been made easy to watch for changes in several frequently changing and growing data items:

• GPS logs,
• Trips,
• Status data,
• Fault data and,
• Exception events

A couple if these data items reference other entities that rarely change, however, and should not be queried via the API each time new data is received. These include:

• Engine.UnitOfMeasure
• Engine.Source
• Engine.FailureMode
• Engine.Diagnostic
• Engine.Controller

Best practices for these items is to load them all into a caching dictionary (keyed on Id) when your SDK application first starts up, and look up the values in there as necessary, refreshing if you’d like once per day. This will almost certainly make your application run faster, as it won’t be delayed by additional server calls.

For more information on the DataFeed, see the API reference for GetFeed, and read more about handling DataFeed results.

Keep building

Geotab has seen some great third-party SDK integration work being done in the past year, and is continually committed to improving and making it easier to work with. After all, MyGeotab uses the same set of APIs available to third parties, so Geotab developers are also Geotab API users.

For more information about our SDK, please see our SDK documentation as well as our SDK forums.