Hello @大地 三浦 ,
Thank you for such a well-structured question and for asking it here in our community. I am not a developer and I did use an AI tool to help me put these sources together to address your questions. If you have any follow up questions or anything doesn't make sense I will be happy to pull in one of our developers.
The honest answer is: Geotab does not publicly document a server-side timeout value for /apiv1 requests. Here is what the documentation does and does not say, broken down by what you asked.
What Is and Isn't Documented
The 300-second figure is client-side, not server-side. The MyGeotab Python SDK sets a default timeout=300 parameter on the HTTP client — this controls how long your process waits before abandoning the connection and raising a TimeoutException. It says nothing about when the Geotab server itself would terminate a long-running request. There is no official Geotab documentation that states a server-side timeout value for standard /apiv1 calls.
The one exception: GetFeed has a documented per-request timeout.
The API reference explicitly states a 180-second timeout applies to GetFeed requests. This is the only method where a server-side time limit is formally documented.
Rate limits and result limits are documented separately.
These are not timeouts but are worth knowing if you are making heavy queries:
- GetFeed for StatusData, LogRecord, FaultData, Trip, etc. is rate-limited to
1 request per second per user+database
- Get requests that return more than 500 MB of data result in an OverLimitException
- Result sets are implicitly capped server-side (50,000 records for some entity types, with more to follow)
Practical Guidance
For Authenticate and Get Device — these are lightweight and will complete in well under a second under normal conditions. Timeout is not a practical concern.
For Get LogRecord and Get StatusData — the risk is not timeout but result size. If your query spans a wide date range or a large fleet, you will hit result limits before you hit any time limit. Use fromDate/toDate with narrow windows and paginate via GetFeed for bulk retrieval.
The safest design approach regardless:
- Set your HTTP client timeout to at least 300 seconds for heavy Get queries
- Use GetFeed for large data pulls rather than open-ended Get — it is designed for that pattern and its 180-second server limit is predictable
- Handle OverLimitException and retry with a narrower date range
If you need a definitive answer I can talk with our developers or we can make a support case to see if we can get more information that may not be publicly documented.
Please let us know if you have any other questions. We are here to help.
Have a great day!
Eishi FUN
Sources:
- MyGeotab Python SDK — timeout parameter (https://mygeotab-python.readthedocs.io/en/latest/api.html)
- Geotab Result and Rate Limits — Geotab Blog (https://www.geotab.com/blog/result-and-rate-limits/)
- Better Practices for the MyGeotab API — Geotab Blog(https://www.geotab.com/blog/better-practices-mygeotab-api/)
- MyGeotab API Concepts — Geotab Developers (https://developers.geotab.com/myGeotab/guides/concepts/index.html)