<h1> </h1>Hello Integrators, Starting Monday, November 9, 2026 the Data Intake Gateway (DIG) will apply a rate limit to the &#x2F;records endpoint. The limit keeps ingestion stable and fast for everyone by stopping any single integration from using too much capacity during a sudden traffic spike.<h2>What's changing</h2><ul><li>POST &#x2F;records will be limited to 1,000 requests per minute.</li><li>As with DIG's existing rate limits, the limit is counted against both your DIG user account and your source IP address. A request that goes over either one is rate limited.</li><li>The limit counts requests, not records. A request is counted the same whether it carries one record or many.</li><li>Rate-limited requests receive HTTP 429 TOO_MANY_REQUESTS with a Retry-After header (RFC 6585). Records in a rate-limited request are not accepted and must be sent again.</li><li>Nothing else changes: request and response formats, the &#x2F;invalidrecords endpoint, and the existing authentication limits stay the same.</li></ul><h2>Who may be affected</h2>The limit is set well above typical integration traffic and is meant as a safeguard against sudden spikes. Integrations that batch their records are unlikely to be affected. Please review your integration if you:<ul><li>send many small requests, for example one request per device or per record, instead of batching records together</li><li>run several DIG user accounts from the same source IP address, because these share one IP limit</li><li>expect a big increase in device count or reporting frequency, or plan to load large amounts of historical data</li></ul><h2>What you should do</h2><ol><li>Handle 429 responses. Wait the number of seconds given in Retry-After, then send the same request again. Don't treat a 429 as a permanent failure, and don't drop the records.</li><li>Back off with jitter. Add a small random delay to retries so queued requests don't all retry at the same moment.</li><li>Batch your records. We recommend 200–500 records per request on average. At 500 records per request, 1,000 requests per minute allows up to 500,000 records per minute.</li><li>Pace large loads. Spread out historical loads and catch-up after an outage instead of sending as fast as possible.</li></ol><h2>Questions</h2>If you have questions about this change or for any resulting production issues, please submit a support ticket through MyAdmin. Or ask on this thread below!

Upcoming change: Rate limiting on the Data Intake Gateway (DIG) /records endpoint

<a data-id="1143" data-value="DFenn-1143" data-denotation-char="@" href="/user/dfenn-1143" class="text-decoration-none mention">@DFenn-1143</a> Geotab has been recommending to migrate away from using Trailers and TrailerAttachment in favor of Devices and DeviceLink. Give that a shot and see if it does what you need: https:&#x2F;&#x2F;developers.geotab.com&#x2F;myGeotab&#x2F;apiReference&#x2F;objects&#x2F;DeviceLink&#x2F;

How do I associate a Trailer to a DutyStatusLog?

<a data-id="1087" data-value="TuckerBA-1087" data-denotation-char="@" href="/user/tuckerba-1087" class="text-decoration-none mention">@TuckerBA-1087</a> I saw that and took that to mean that was the limit when using pagination. I had already switched to using pagination, but wanted get the definitive answer. So now I know. Thanks for the clarification.

Get Device is being limited to 5000 records in MyGeotab SDK

Hi Eishi and Felipe, thank you both for your responses and for looking into this. @Felipe_Hoffa, to answer your question: we are looking to interpret the sequence of events for device cellular connectivity health monitoring, specifically to calculate accurate uptime and availability metrics. To give you a bit more background on our current process, we have been using a report template from the &quot;Log Data and Collisions&quot; module, and recently implemented a script that queries <code>debugData</code> via the MyGeotab API. I appreciate any insights you and the MCP team can share on this!

Extracting DebugData (debug records) via the MyGeotab MCP Connector

hi Geotab devices don't natively send TAIP messages. To integrate them into a computer-aided dispatch (CAD) system, you need to use middleware: 1. Pull the positions from the Geotab cloud using the Data Feed API (the 'GetFeed' method for 'LogRecord'). 2. Convert that data to the TAIP format in your middleware. 3. Send the converted messages to the CAD system.

Dispatch MyGeotab Integration

<a data-id="12250" data-value="richardprater" data-denotation-char="@" href="/user/richardprater" class="text-decoration-none mention">@richardprater</a> Geotab supports SSO via SAML 2.0. Here are the docs: <a href="https://docs.google.com/document/d/1HlFpXjG09JOaRaf7ocXGEPsWVDGvjWOofz18h8DZL18/edit#heading=h.6gqkmkwes4dm" target="_blank">MyGeotab SAML 2.0 SSO Integration Guide</a> For your other questions:<ol><li>`trip.distance` is in km: <a href="https://developers.geotab.com/myGeotab/apiReference/objects/Trip/index.html" target="_blank">https:&#x2F;&#x2F;developers.geotab.com&#x2F;myGeotab&#x2F;apiReference&#x2F;objects&#x2F;Trip&#x2F;index.html</a></li><li>Check out the FuelTaxDetail documentation: <a href="https://developers.geotab.com/myGeotab/apiReference/objects/FuelTaxDetail/index.html" target="_blank">https:&#x2F;&#x2F;developers.geotab.com&#x2F;myGeotab&#x2F;apiReference&#x2F;objects&#x2F;FuelTaxDetail&#x2F;index.html</a></li><li>This one I'm less sure of. I know you can select demo vocations and demo vehicles, but I don't know that they cover your specific requirements. This document might help you: <a href="https://support.geotab.com/help/mygeotab/access-and-administration/getting-started/database-setup#ariaid-title4" target="_blank">https:&#x2F;&#x2F;support.geotab.com&#x2F;help&#x2F;mygeotab&#x2F;access-and-administration&#x2F;getting-started&#x2F;database-setup#ariaid-title4</a></li></ol>

Third-party app for owner-operators: OAuth/delegated access, or a service-account user?

It was my understanding that, although the standard&#x2F;free versions of Gemini do not directly support MCP connections, the Enterprise - Business version does support them (as a &quot;Pre-GA&quot; feature). I may be missing something, so I'll provide a link for reference: https:&#x2F;&#x2F;support.google.com&#x2F;g&#x2F;answer&#x2F;17106276?hl=en Thanks!

Gemini availability for Geotab MCP Connector

<a data-id="1143" data-value="DFenn-1143" data-denotation-char="@" href="/user/dfenn-1143" class="text-decoration-none mention">@DFenn-1143</a> I am not sure on the QA. I know a few months back they began pushing accounts to be real emails even on private apps and service accounts we were told to start migrating. You said you use fake emails anyway? I would pick a way that you can make work but I would count on having to have a real email just in case. You can just create a logic app to handle all incoming email to that one email account. It still satisfies the other requirements.

Auto-Login using URL Integration

+1 to this point. Is there a reason that you're looking for the max version specifically? If it's just to know when to stop asking for results, I would recommend exactly what <a data-id="1145" data-value="LPPapillon-1145" data-denotation-char="@" href="/user/lppapillon-1145" class="text-decoration-none mention">@LPPapillon-1145</a>suggests and simply loop until there are no more to get. For high-activity feeds, the version is likely to be a moving target anyway - you might find the current latest record and have additional records added by the time you're done looping and processing the first batch.

Geotab SDK GetFeed call never reaches max version

Tucker's response will most likely get you what you need. You might also be able to query the API for all Devices in your database and filter them by their deviceType. That should let you identify all GO devices in your database without needing to try and parse out their serial numbers.

How to identify GO Devices with the C# SDK?

Hi <a data-id="11643" data-value="jkwong" data-denotation-char="@" href="/user/jkwong" class="text-decoration-none mention">@jkwong</a> , welcome to the Community! We are glad you are here! The enriched fields are available as properties of the MyGeotab FaultData API object, including: - severity - riskOfBreakdown - failureMode - faultDescription - recommendation - effectOnComponent You can request them using Get or GetFeed for FaultData. However, these fields may be null when enrichment is unavailable for a particular fault. The API documentation confirms that the fields exist, but does not guarantee that every value shown in the MyGeotab UI will be populated for every Noregon-enriched record. I recommend testing the API against a known enriched fault and comparing the response with the corresponding record in MyGeotab. The current API reference is available here: https:&#x2F;&#x2F;developers.geotab.com&#x2F;myGeotab&#x2F;apiReference&#x2F;objects&#x2F;FaultData&#x2F; Hope that helps! Eishi FUN

GeoTab Fault Data - Enriched with Noregon - API Access?

<a data-id="11959" data-value="bikiran" data-denotation-char="@" href="/user/bikiran" class="text-decoration-none mention">@bikiran</a> Thank you for following up when you found the answer. We appreciate this contribution to the communities collective knowledge. Please feel free to reach out if you ever have any other questions.