Hi <a data-id="1203" data-value="Gus_Rubio10" data-denotation-char="@" href="/user/gus_rubio10" class="text-decoration-none mention">@Gus_Rubio10</a> , great question thank you for asking it here in our community! The Geotab Data Connector officially supports the following tools: Microsoft Power BI, Microsoft Excel (via Get Data&#x2F;Power Query), and Tableau. Looker Studio is not on the officially supported list. That said, the connector uses an OData connection, so it may technically work with other tools that support OData — but those tools haven't been officially tested and wouldn't be eligible for support if you run into issues. For full details, the Geotab Data Connector documentation (https:&#x2F;&#x2F;support.geotab.com&#x2F;help&#x2F;mygeotab&#x2F;industry-and-advanced-features&#x2F;geotab-data-connector&#x2F;geotab-data-connector) has a complete breakdown of supported tools and how to connect them. Feel free to reach out if you have any other questions. We are here to help. Have a great day! Eishi FUN

Geotab data connector

Hey <a data-id="6441" data-value="eiler-6441" data-denotation-char="@" href="/user/eiler-6441" class="text-decoration-none mention">@eiler-6441</a> , Hi, great question and one that is worth investigating properly. I think I know what is going on here based on some recent changed with MyGeotab logins. What you are probably experiencing is related to the Unified Login rollout which is a centralized identity platform that new databases are now on by default. Older databases use a legacy per-database authentication model where the username and email were effectively the same field, but new databases on Unified Login enforce a separation between the local username and the email identity. This change is what is causing the inconsistency you are seeing between old and new companies. For integrators creating users via the API against new databases, the handling is different and the current documentation may not fully reflect this yet. I would recommend: 1. Reviewing the Unified Login overview (https:&#x2F;&#x2F;support.geotab.com&#x2F;help&#x2F;mygeotab&#x2F;access-and-administration&#x2F;log-ins&#x2F;unified-login-overview) for context on how the new identity model works 2. Opening a support ticket so our team can advise on the correct API approach for creating users on Unified Login databases — this is a technical integration question that needs specific guidance We want to make sure this is properly documented for developers. Thank you for flagging it. Have a great day! Eishi FUN

API Error

<a data-id="1451" data-value="Sajad-1451" data-denotation-char="@" href="/user/sajad-1451" class="text-decoration-none mention">@Sajad-1451</a> Thank you! That is helpful context regarding generous API limits. The release of those skills should make this MCP much more useful&#x2F;impactful.

MCP - GetDirections, GetFeed, etc...

⚠️ Transition Away from Legacy EV Data Endpoints In the early days of fleet electrification, we developed three original API endpoints to provide trailblazing companies access to Geotab-calculated EV insights. We now have better data objects that deliver the same insights in a more accurate and scalable way. These legacy endpoints are no longer officially supported. We strongly encourage our partners to transition to the new data objects by early 2026 to ensure seamless operation and avoid disruptions. Legacy Endpoint Deprecation Schedule The following legacy endpoints will be deprecated and should be replaced by the suggested data objects:<ul><li>GetBatteryStateOfHealth<ul><li>Deprecation Target: September 26, 2026</li><li>Suggested Replacement: <a href="https://developers.geotab.com/myGeotab/apiReference/objects/BatteryStateOfHealth/index.html" target="_blank">BatteryStateOfHealth</a></li></ul></li><li>GetRangeCapability<ul><li>Deprecation Target: September 26, 2026</li><li>Suggested Replacement: <a href="https://developers.geotab.com/myGeotab/apiReference/objects/RangeEstimate/index.html" target="_blank">RangeEstimate</a></li></ul></li><li>GetRealTimeRange<ul><li>Deprecation Target: September 26, 2026</li><li>Suggested Replacement: <a href="https://developers.geotab.com/myGeotab/apiReference/objects/EVStatusInfo/index.html" target="_blank">EVStatusInfo</a></li></ul></li></ul> ✨ What's Better About the New Data Objects? The new data objects are superior to the legacy endpoints they replace, offering significant advantages:<ul><li>Better Performance: Get results up to 10x faster than legacy endpoints.</li><li>More Accurate Results: Our updated EV range model provides greater precision. The RangeEstimate object has confidence intervals to represent the level of certainty in the calculated EV range.</li><li>More Options for Requesting Results: The new data objects are compatible with the standard Get() method and DeviceSearch. This allows you to use Geotab-standard search criteria to return the specific results you need, for the devices you want.</li><li>More Useful Information: In addition to real-time range, EVStatusInfo now includes an estimate of the charge complete time, helping you predict when an EV will finish charging.</li></ul> 💡 Help Is Available Need assistance working with the Geotab API, including the latest EV data objects?<ul><li>Everyone can post questions to the Integrator's Hub on Geotab community.</li><li>Fleet customers can send questions to their reseller partner.</li><li>Resellers and marketplace partners can send questions to their solutions engineering contact or partner account manager.</li></ul>Useful Resources<ul><li><a href="https://www.google.com/search?q=https://www.geotab.com/support/electric-vehicle-data-diagnostics-and-api-user-guide" target="_blank">Electric Vehicle Data Diagnostics and API User Guide</a></li><li><a href="https://www.google.com/search?q=https://developer.geotab.com" target="_blank">Developer site</a></li><li><a href="https://docs.google.com/document/d/1gFtXqnZEtyERUj47gnzW12itF-I-lERDgvpiPWchc38/edit?usp=sharing" target="_blank">EV Data Over API - Transition away from legacy endpoints DOC</a></li></ul>

📣EV Data API Legacy Endpoint Deprecation 📣 : September 26, 2026

<a data-id="1087" data-value="TuckerBA-1087" data-denotation-char="@" href="/user/tuckerba-1087" class="text-decoration-none mention">@TuckerBA-1087</a>- More sections to link to the finer details. It might be just how the new Development pages are generated, but the current method used to create a Table of Contents is very inconsistent. Sometimes it uses details tags, other pages use section tags and header tags, and barely used at all. For this feedback generally, a link to https:&#x2F;&#x2F;developers.geotab.com&#x2F;myGeotab&#x2F;guides&#x2F;goDeviceLogging&#x2F;index.html#odometer, resolving to the odometer header, would be great as a direct link. Similar issues with the TOC existing on other pages, like https:&#x2F;&#x2F;developers.geotab.com&#x2F;myGeotab&#x2F;addIns&#x2F;developingAddIns From what I can see, several pages have not been updated to match the new requirements compared to when it was hosted on GitHub Pages, back in the day.

Developer Documentation Improvement - GO Device Logging

<a data-id="8083" data-value="mdevol" data-denotation-char="@" href="/user/mdevol" class="text-decoration-none mention">@mdevol</a> Hey I did get an update that there is a myG update they are waiting on so this will be held up until next Tuesday. If I hear anything else I will let you know.

Getting PlatformNotSupportedException when authenticating to GeoTab

<a data-id="1546" data-value="ssartor-1546" data-denotation-char="@" href="/user/ssartor-1546" class="text-decoration-none mention">@ssartor-1546</a> thank you

Export MyGeotab data to Power BI

With a lot of the documentation on the MyAdmin API being updated to V3, is there also a plan to update the runner and the Using With JavaScript downloads to be more V3 compliant?  This would allow testing pagination and other new features V3 is intended to provide.  Is there any possibility of having an API client similar to the Geotab JavaScript client (https://github.com/Geotab/mg-api-js) created for the MyAdmin APIs? While I know the possible usage scope is a little different, and working on my own MyAdmin API class is likely a time sink that I would be interested in undertaking. Something more official in the long term would be nice 

Development Page for MyAdmin still uses V2, not V3

Hi Team,We pull data for our fleet via the API. We call teh various api endpoints on a daily basis and ask for the last 48 hours of data, so every day there is an overlap of 24 hours in case any data is missed.Even doing that though, often we find that if we go back at month end and pull the whole month we fill in gaps with missing data. What's the best method of pulling the data from the geotab datasets to avoid this? We pull a lot of different callsevents, trips, odometers, engine hours, log status, etc etc. Would really appreciate knowing how we can pull the data using a reported date instead of the event date so we know we've got everything, thanks 

Method of get late reporting assets

Hi Geotab Community,I'm integrating with the MyGeotab API using JSON-RPC over HTTP POST to:https://my.geotab.com/apiv1​I would like to know the server-side timeout for MyGeotab API requests.Specifically, does MyGeotab terminate API requests after a fixed amount of time on the server side, API gateway, or backend?For example, if I call methods such as:AuthenticateGet for DeviceGet for LogRecordGet for StatusDatais there a documented maximum request processing time before the server returns an error or closes the connection?I checked the MyGeotab API documentation, but I could not find a clear statement about the server-side timeout value for /apiv1.Any official reference or guidance would be appreciated.Thanks!

What is the server-side timeout for MyGeotab API (/apiv1) requests?

Hi, We are building a reporting pipeline that replicates MyGeotab exception rule durations using the SDK. We have been able to match results for most vehicles, but we are seeing consistent discrepancies on units with sparse logging for rules based on Engine Speed thresholds. **Rule structure:** Status Data Diagnostic "Engine speed" &gt; 1200 RPM AND Status Data Diagnostic "Engine speed" &lt; 1400 RPM **How we currently process the data:** We download StatusData for DiagnosticEngineSpeedId and build a time series. For each consecutive pair of logged points, we calculate the interval duration and distribute that time proportionally across RPM ranges using linear interpolation between the two endpoint values. For large gaps where the device did not transmit, we interpolate between the last known value before the gap and the first value after it, using the full gap duration. Interestingly, reprocessing the same rule via the MyGeotab UI produces the same durations as the original — which suggests the data used for the calculation is persisted on the platform. **Our specific questions:** a) When MyGeotab evaluates an RPM-based exception rule, does it use only the StatusData records available via the SDK, or does it also use an internal higher-resolution data store not exposed through the API? b) Is there a StatusData search parameter, result type, or API endpoint that returns intermediate logged values not returned by a standard fromDate/toDate query? c) For a rule like the one above, does MyGeotab interpolate linearly between consecutive StatusData points to estimate duration within the threshold, or does it only count time when a logged point explicitly falls within the range? d) Are there any other diagnostic IDs, data types, or API calls we should be using to get the full Engine Speed time series that MyGeotab uses internally for exception calculation? Thank you,

RPM Values

<a data-id="1044" data-value="EishiFUN" data-denotation-char="@" href="/user/eishifun" class="text-decoration-none mention">@EishiFUN</a> Thank you so much for the update. I really appreciate you taking the time to clarify things. Thanks again for following up!