Geotab API: Fleet Workflows Carly Can Run
When a truck crosses a geofence, Carly can tell the customer it arrived before dispatch has to look up from the board. The same connection turns harsh-driving exceptions into coaching tasks, diagnostics into maintenance follow-up, and Geotab’s location, trip, vehicle, and driver data into useful recurring fleet briefs.
There is no Geotab developer key, and you don’t need one. Geotab’s own getting-started guide says it directly: “You do not need a separate developer API key. You need a MyGeotab database, an appropriately scoped user, and an integration design.”
Your MyGeotab credentials are your API credentials. That’s simpler than most telematics platforms — and it comes with a set of consequences that catch people out, starting with the fact that this isn’t a REST API at all.
Fleet workflows Carly can run
Geotab splits neatly into events Carly can receive instantly and fleet data Carly checks on a recurring schedule.
These can happen the moment they happen, because each is expressible as a Geotab exception rule:
- Speeding or harsh driving that reaches the manager same-day, with the driver and vehicle attached, instead of surfacing in a weekly coaching report after the fact.
- Geofence arrivals that notify the customer, so nobody is manually texting “he’s on site.”
- Idling thresholds that open a coaching task rather than accumulating quietly in a report.
These need checking on a schedule instead — trips, raw location history, fault codes, and hours-of-service data don’t push, so anything built on them runs on a timer rather than instantly.
That split is the single most useful thing to understand about automating Geotab, and the rest of this page explains why it exists.
For example:
When a harsh-driving rule fires, identify the driver and vehicle, send the manager the event and recent context, create a coaching task, and include it in Friday’s safety brief.
Or:
Every morning, send operations a fleet brief covering vehicles with new fault codes, upcoming maintenance, unusual idling, yesterday’s utilization, and anything that needs a person today.
Create a service account, not a personal login
The recommended way to give Carly durable, scoped access is a service account — a user row flagged for API use. Geotab: “Service accounts allow your solution to make API requests against a MyGeotab database outside of active user sessions.”
Path: People → Users & Drivers → Add. A customer admin creates this themselves; view-only clearance is recommended for read integrations, and writes need a custom clearance beyond that.
One quirk that wastes time: “Attempting to use service account credentials to log in via the UI will result in an error.” So you can’t sanity-check the account by logging into MyGeotab with it. It works via API and nowhere else.
On resellers — Geotab sells through them, but that doesn’t gate API access. A customer with Administrator or Supervisor clearance on their own database creates the service account without reseller involvement. A reseller can do it for you, in which case the customer must consent.
It’s JSON-RPC, and that breaks most tooling
This affects the calls under the hood, but not how you connect it to Carly: add Geotab natively from Carly’s Integrations tab, and Carly handles the JSON-RPC shape.
Everything goes to one URL: https://[myserver]/apiv1. You POST a method name in a JSON body.
{"method":"Get","params":{"typeName":"Device"}}There are no REST resources. No GET /devices/{id}, no HTTP verbs carrying meaning. Reads, writes, and deletes are all POST /apiv1 with method set to Get, Add, Set, or Remove.
The practical consequence: OpenAPI generators and generic REST clients don’t understand Geotab without extra handling. Carly handles that API shape inside the native Geotab connection, so users don’t need to build an adapter themselves.
Server discovery is a second surprise. Authenticating against my.geotab.com returns a path — either a real server URL like my3.geotab.com, or the string ThisServer. Your database physically lives on a regional server, and my.geotab.com is only a directory. Worse, databases move between servers in the federation without notice. Hardcoding the server you got on day one breaks silently later; the correct pattern is re-running Authenticate and following path when a call fails.
Rate limits are tiered by fleet size
Limits apply per unique combination of method, entity, username, and database, multiplied by fleet size:
| Tier | Tracked assets | Multiplier |
|---|---|---|
| 1 | 0–1,000 | ×1 |
| 2 | 1,001–10,000 | ×5 |
| 3 | 10,001–25,000 | ×15 |
| 4 | 25,001+ | ×25 |
At Tier 1, GetFeed sits at 60 per minute for most entities — LogRecord, StatusData, FaultData, ExceptionEvent, Trip, and others. Web methods are fixed regardless of tier, and two are tight enough to design around: Authenticate is 10 per minute and SetUserPassword is 2 per minute.
Here’s the part worth reading twice: the published limit tables carry an Active/Inactive status column, and most Get limits are published but not yet enforced. The GetFeed limits are largely active. So building against the generous Get numbers means building against limits Geotab has explicitly staged to switch on later.
Exceeding returns an OverLimitException plus a Retry-After header. Successful responses carry X-Rate-Limit-Limit, -Remaining, and -Reset.
Separately, a 50,000 result cap per Get applies to AnnotationLog, DVIRLog, TrailerAttachment, IoxAddOn, CustomData, and BinaryData.
Errors come back as HTTP 200
This is the single most important thing to know before writing a client.
A bad-credentials Authenticate returns HTTP 200 with a JSON-RPC error body — {"error":{"type":"InvalidUserException","code":-32000}}. Any client that branches on HTTP status treats every failure as a success. You have to parse the body for an error key on every response.
Two more session traps: sessions expire after 14 days, and there’s a 100-session cap — the 101st authentication expires the first. A naive client that authenticates on every request quietly evicts its own sessions, and its colleagues’, while burning through a 10-per-minute Authenticate limit. (Some older sources say 30-day sessions; current docs say 14.)
Push exists, but only for rule-shaped events
This distinction determines whether Carly starts immediately from a Geotab event or runs the work on a schedule.
The API itself is poll-only, and Geotab explains why: “A push-based approach would require Geotab to connect to another organization and this invariably means firewall traversal is required.” Sync happens through GetFeed with fromVersion continuation tokens — you persist toVersion and re-poll, faster when a full page returns, backing off when idle.
But MyGeotab rules can push. Exception rules support four notification types, and one of them is Web Requests: “Web requests allow you to make an HTTP GET or POST requests in order to use exception data outside of MyGeotab.” You supply an endpoint URL, pick GET or POST, and template the payload with tokens.
So the honest summary is: rule-shaped events push, arbitrary data doesn’t. Speeding, geofence entry and exit, idling, harsh driving, and custom diagnostic thresholds can all reach your endpoint the moment they fire, because each is expressible as an exception rule. Raw GPS, trips, status data, fault codes, and HOS are poll-only.
The web-request payload format isn’t fully documented — Geotab’s support article doesn’t specify headers or the complete token list. Expect some trial and error.
Your plan gates the data, not the API
The Carly workflow can only reason over data the fleet’s plan actually records.
The rate plan question gets asked constantly and the framing is usually wrong.
First, a correction: Regulatory, Pro, and ProPlus are legacy plans no longer sold to new customers. The current lineup is Base / GO Core and the GO Plan.
API and SDK access is available on all plans — full integration and customization is listed across the lineup. What differs is what data exists to read. On Base/GO Core, engine data is limited to odometer, engine hours, and engine road speed: no accelerometer data, no EV data, no HOS. Regulatory added HOS, IFTA, and tachograph. Pro added engine, accelerometer, and EV data.
The practical effect is subtle and worth guarding against: an integration querying StatusData for EV battery state on a Base database doesn’t error. The call succeeds and returns nothing, because the data was never collected.
MyAdmin is a different API
Worth clearing up since search results conflate them. The MyAdmin API lives at myadminapi.geotab.com and is “available for Geotab Resellers and Partners” — it covers billing, device orders, and account administration. It is not fleet telematics data, and an ordinary fleet operator doesn’t need it.
The Geotab Marketplace is a vetted catalog of third-party solutions, not an API. It matters only if you want a listing.
How Carly completes the fleet workflow
An exception rule firing a web request is a real event trigger — one of the better ones in telematics. What’s usually missing is anything on the receiving end doing more than logging it.
Handing that to an AI assistant hits a specific wall.
The unattended-work gap closed in 2026: ChatGPT Scheduled Tasks and Claude Cowork both run on their own. The remaining gap is what starts them. These run on a timer, not in response to an event in your apps, so "when this happens, do that" is still outside what they do.
“Summarize last week’s harsh-braking events” is well within what ChatGPT or Claude will do with a Geotab export. “Notify the driver’s manager and open a coaching task the moment the rule fires” is not, because nothing on that side is listening for the rule.
Carly covers that half:
- Receives the Geotab web request — the exception rule fires, Carly acts, with nobody at a laptop
- Runs the whole response in one flow — read the event, identify the driver and vehicle, draft the message, send it, open the task
- Actually sends — Gmail and Outlook, with attachments
- Handles the polling side too — for the data that has no rule, a scheduled
GetFeedsweep with properfromVersionbookkeeping is exactly the tedious job worth automating
Because Geotab exposes an API, you can connect it natively to Carly from the Integrations tab with the service-account credentials. Carly handles Geotab’s JSON-RPC shape and can use it in on-demand, recurring, and event-triggered workflows. AI agents start at $35/month, and workflow steps that don’t use AI run free and unlimited.
Frequently Asked Questions
Do I need a Geotab developer key?
No. Geotab issues no separate developer API key — your MyGeotab database credentials are the API credentials. The recommended setup is a service account created under People → Users & Drivers, with clearance scoped to what the integration needs.
Is the Geotab API REST?
No, it’s JSON-RPC. Every call is a POST to a single /apiv1 endpoint with a method name in the body. Generic REST tooling and OpenAPI generators need extra handling, which Carly takes care of through its native Geotab connection.
Does Geotab support webhooks?
Partly. The API itself is poll-only via GetFeed. But MyGeotab exception rules support Web Request notifications, so anything expressible as a rule — speeding, geofence entry and exit, idling, harsh driving, diagnostic thresholds — can push to your endpoint. Raw GPS, trips, and HOS data remain poll-only.
Which Geotab plan do I need for API access?
All of them include API and SDK access. What your plan changes is which data is collected: Base and GO Core have no accelerometer, EV, or HOS data, so those queries return empty rather than erroring.
Why do my Geotab API errors show as successful responses?
Geotab returns HTTP 200 even on failure, with the problem described in a JSON-RPC error object in the body. Clients that check only the HTTP status treat every error as success — parse the body instead.
More: AI agents for ops · Best AI workflow automation tools · Best AI agents for productivity
Ready to automate your busywork?
Carly schedules, researches, and briefs you—so you can focus on what matters.
See what people say
"Before Carly, I relied on a Calendly link, but the whole process felt impersonal and not very professional. Carly changed that by handling all the back-and-forth, so I'm no longer stuck in endless email threads trying to line up schedules.
Now Carly reaches out to candidates, shares my real-time availability, lets them pick a slot, then sends a Zoom link and drops it straight into my calendar. She sends reminders to both of us before each call, which has significantly reduced no-shows and last-minute confusion.
On top of scheduling, Carly acts like a full executive assistant, sending me my schedule the night before so I can prepare for each call. It reminds me of the old x.ai assistant, but Carly is noticeably smarter, faster, and better suited to my healthcare recruitment business."
