The short version
The renewal quote is on your desk and it has a new line on it. A customer asked for a portal where they can see their own vehicles. Dispatch wants a rule the alert editor cannot express. Finance wants trips joined to invoices. Every answer from the vendor has been another per-vehicle add-on, so you typed samsara api integration, or geotab api integration, because you suspect the data could just be used directly.
It can. Both vendors publish a real API, and the hardware you already paid to install keeps doing exactly what it does today. What changes is where the features live. Built inside the catalogue, a feature is rented and leaves with the contract. Built on the API, it is yours and it survives a vendor switch. That is the whole argument, and nobody has to rip anything out of a truck to act on it.
One warning before the detail. The two APIs are not the same shape. Samsara will push events to you. Geotab will not, by design, so you poll. Which one you have decides what the first month of engineering looks like, and most agencies quoting this work have never read either set of docs closely enough to tell you that.
How do the Samsara and Geotab APIs actually differ?
They differ on push, on pagination and on how the limits are counted. Everything below comes from the vendors' own developer documentation as published at the start of September 2026, not from a sales deck, and where we could not verify a figure we say so rather than guess.
| What you need to know | Samsara | Geotab (MyGeotab) |
|---|---|---|
| Authentication | API token or OAuth 2.0, bearer header, HTTPS only | Authenticate call returns a session credential. Sessions last up to 14 days, and a user account can hold 100 concurrent sessions before the oldest expire |
| Rate limits | 150 requests a second per token, 200 a second per organisation, with endpoint categories capped as low as 100 a minute | Per-method, per-minute caps multiplied by a tier set by tracked assets: x1 up to 1,000 assets, x5 to 10,000, x15 to 25,000, x25 above. Base examples in the official table: Device Get 650 a minute, Device GetFeed 250 a minute |
| Over the limit | HTTP 429 with a Retry-After header in seconds | OverLimitException with a Retry-After header, plus X-Rate-Limit-Limit, Remaining and Reset headers on every limited call |
| Pagination | Cursor based: pass after, read endCursor and hasNextPage. Default and maximum page is 512 records, cursors expire after 30 days | Version based: GetFeed returns records plus a toVersion token, you pass it back as fromVersion. Result limits vary by entity and are set per call |
| Push to your system | Yes. Alert webhooks and event subscriptions, HMAC SHA-256 signed in the X-Samsara-Signature header, five delivery attempts with exponential backoff | No. The data feed guide states a push model would require Geotab to connect through your firewall, so polling GetFeed is the documented pattern |
| Getting history out | Through the same paginated endpoints | GetFeed from version 0 or from a date replays the stream. Full database export is an admin feature, and retention beyond the default is a support conversation |
Read the table as an engineer would. Samsara's model is a modern REST API you can mostly treat like Stripe. Geotab's model is a synchronisation feed, closer to a replication log than a query endpoint, and it rewards a different design: a poller that remembers where it got to, calls again immediately when a page comes back full, and slows down when nothing changes. Their own guide describes exactly that adaptive loop.
One thing we could not settle. Community posts quote a hard cap on records per GetFeed call that does not appear in the official rate limit guide. We build to the official table and treat the community figure as a rumour until a vendor page says it.
What does staying inside the vendor's add-on catalogue cost you?
Not money, or not first. The fleet hub on this site already covers the per-vehicle arithmetic in our custom fleet management software guide, and if that is your question, start there. This page is about the thing that arithmetic hides.
Every feature you configure inside the vendor's product is a feature the vendor owns. The customer portal you switched on is their portal with your logo. The report you built in their editor lives in their editor. When the renewal comes back higher, or when a second business unit turns up already on the other vendor, every one of those features is a reason you cannot move. The per-vehicle line grows with the fleet. The things you built on top of it are rented.
The practical consequence shows up in three places. Sales loses a deal because a prospect wanted their vehicles inside the prospect's own system and you could only offer a login to yours. Finance reconciles trips against invoices by export and spreadsheet every month, because the join never existed. And operations keeps a rule in someone's head that the alert editor could not hold. None of those is a crisis on its own. Together they are the reason you are reading a page about APIs at renewal time.
Who should not build on the API at all?
Most fleets under a couple of hundred vehicles, and it costs us work to say so.
If you run one vendor, your needs are reminders, maintenance workflow and a tidier report, and nobody outside your company ever has to log in, do not build anything. Fleetio's marketplace integration, Zapier's Samsara connector or the vendor's own app marketplace already cover that, and the vendor keeps them working when the API changes. Building your own integration for a workflow problem gives you a second system to maintain and no feature your team can see.
There is a second group who should wait. If your only pain is the price, the API does not fix it. Your data still lives with the vendor, the hardware still reports to the vendor, and you still pay per vehicle. What changes when you build on the API is ownership of the features and the history, not the subscription. If the subscription itself is the problem, that is the build-versus-buy decision in the hub guide, and it has a different answer at different fleet sizes.
Come back to this page when a customer, a billing rule, or a second vendor needs data in a shape the catalogue will not give you. Those three are the real triggers.
What can you actually build on top of the data?
Building on telematics data means taking the vehicle positions, trips, engine status and events the vendor already collects, pulling them through the published API into a store you control, and putting your own application on top. The hardware, the cellular link and the vendor's platform stay exactly as they are. Your product starts one layer above them.
Four things account for nearly every request we see, and the order matters.
A customer-facing portal. Equipment hire, last-mile contractors and field service operators all get asked the same question by their own customers: where is my thing right now. A portal that shows a customer only their assets, with their own users and their own alert preferences, is the single most common build, and it is a multi-tenant application problem more than a telematics one. The vendor's shared login was never designed for it.
A dispatch rule the editor cannot hold. Vendor alert editors handle thresholds well. They handle state badly: a rule that depends on the last three stops, on which driver is assigned today, or on a job that lives in your own scheduling system. Once the rule needs your data as well as theirs, it has to run on your side.
Billing joined to trips. Usage-based invoicing, chargebacks between business units, proof of delivery attached to an invoice line. The join between a trip record and a commercial record is the feature finance keeps asking for, and it only exists if both records land in one place.
Reporting joined to the rest of the business. Fuel against ERP purchase records, utilisation against the maintenance system, driver scores against HR. Each of these is a report the vendor cannot produce because half the data was never theirs.
Every one of these starts with the same first component, an ingestion layer that copies vendor data into your own time-series store as it arrives. On our own 30,000-vehicle fleet platform that store is TimescaleDB with Redis holding the live positions, and the same shape works whether the data arrives from your own hardware or from a vendor API. If your devices report into an IoT builder such as ThingsBoard rather than a fleet vendor, the ceiling arrives differently and our IoT app builder guide walks that version.
Webhooks or polling: which fits a portal, a dispatch rule or billing?
Webhooks fit anything that has to react in seconds, polling fits anything that has to be complete, and the vendor you have already made half the choice for you.
A webhook is the vendor calling your server the moment something happens. Samsara offers this for alerts and for event subscriptions, signs each payload with HMAC SHA-256 so you can prove it came from them, and retries five times with exponential backoff if your endpoint fails. That is the right feed for a dispatch rule or a customer alert, where a geofence exit that arrives three minutes late is a log entry, not an alert. It is the wrong feed for billing, because a webhook you missed during a deploy is a trip you never invoiced, and five retries is not a guarantee.
Polling is your server asking the vendor what changed since last time. Geotab's GetFeed is built for exactly this: every response carries a version token, you pass it back on the next call, and you receive only the records that changed. Nothing is lost if your server was down for an hour, because the checkpoint waited. That is the right feed for billing and history, and with the adaptive loop the guide recommends it is fast enough for a live map. It is a poorer fit for sub-minute alerting, and the per-method rate limits in the table above are the constraint you design around.
So the practical rule is this. On Samsara, run both: webhooks for the reactive features, a scheduled paginated pull for the record of truth. On Geotab, run one well-built poller with a checkpoint per entity type, and derive alerts from the stream on your side. Either way the poller or the receiver writes into your store, and everything you build reads from that store, never from the vendor directly. That separation is what makes the vendor swappable later.
How do you handle more than one telematics vendor?
You normalise once, at the ingestion layer, and nothing above it knows which vendor a vehicle came from.
Multi-vendor fleets are more common than the vendors admit. An acquisition brings a Geotab fleet into a Samsara company. A subcontractor runs Motive. A rented excavator reports through Trackunit. The temptation is to build the portal against one vendor's API and bolt the others on later. The result is a portal with four code paths and four sets of bugs.
The cleaner shape is a small canonical model, a vehicle, a position, a trip, an event, a fault code, and one adapter per vendor that translates into it. Samsara's cursor pages and Geotab's version feed both land in the same tables. The portal, the dispatch rules and the billing job read the canonical tables and never see a vendor field. Adding a fifth vendor is one more adapter, not a rewrite.
There are companies that sell this layer as a product, Terminal and flespi among them, and for a fleet that only needs the normalised feed they can be the right buy. Two honest tests. If you would build nothing on top except a dashboard, buy the layer. If the thing on top is your product, the customer portal you sell or the billing engine your margin depends on, the adapter layer is small enough to own and too important to rent. Motive and Trackunit both publish developer documentation, and we do not quote their limits here because we have not verified them the way we verified the two above.
Who owns the data when you switch platforms?
You own what you have already pulled. You lose access to the rest when the contract ends.
Neither vendor hides this. Samsara's history is available through the same paginated endpoints you use every day, so a nightly job that walks every vehicle's trips into your own store builds the archive as a side effect. Geotab's feed can be replayed from version zero or from a date, and full database export exists as an administrative feature, with longer retention handled through support. In both cases the work is the same: pull it while you have a key, into a store you control.
This is the argument that convinces the people who were not convinced by features. A fleet that has been on one vendor for six years and moves to another loses six years of driver behaviour, fuel patterns and route history unless it copied them out. An integration layer you built for a portal turns out to have been an insurance policy. It is also the reason we put the store between the vendor and the application in every diagram on this page. Swapping the vendor means swapping the adapter. The history, the portal and the billing rules do not notice.
When it is worth handing this to someone
If the catalogue covers you, use it and read no further. If a single Zapier flow or a Fleetio connector closes the gap, do that this week.
The point where it stops being a side project is the first feature that someone outside your company depends on. A customer portal that goes down at their month end, a billing job that double-charged because a webhook retried, a poller that quietly stopped at a version token nobody was watching. This is ordinary engineering, but it is engineering on live vehicles and live invoices, and the vendors' rate limits, retries and session rules are exactly the details that go wrong when they are learned in production.
That is the work we do at Geminate Solutions. We build software products for companies that run fleets and the businesses around them, on top of whichever telematics they already have, and we do not sell rebuilds. The hardware stays. The vendor stays until you decide otherwise. You own the code, the adapters and the store from the first commit. We run our own fleet platform at 30,000+ vehicles, have shipped 50+ products, and hold Top Rated Plus on Upwork at 4.9. If you want to see how we scope this kind of build, our custom software development service page lays out how an engagement runs.
The starting point is the one we would give a friend with a renewal on their desk: a short written review of what your vendor's API will and will not give you, which of the four builds you actually need, and whether you need any of them yet.
Frequently Asked Questions
Can you build a custom app on top of Samsara data?
Yes. Samsara publishes a REST API with token or OAuth 2.0 authentication, cursor pagination at up to 512 records a page, and signed webhooks for alerts and event subscriptions. A customer portal, a dispatch rule or a billing feed can be built against it without changing anything on the vehicle.
Does the Geotab API support webhooks?
No. Geotab's data feed guide says a push model would require Geotab to connect into your network through your firewall, so the documented pattern is polling. You call GetFeed with a fromVersion checkpoint, receive only what changed, and pass the new version back next time.
What are the Samsara API rate limits?
Samsara documents 150 requests a second per API token and 200 a second per organisation, with endpoint categories capped lower, down to 100 a minute for some. Over the limit you get a 429 with a Retry-After header and the docs ask you to back off by that value.
Should I use Fleetio or Zapier instead of building on the API?
Often, yes. One vendor, workflow needs, nobody external logging in: a marketplace integration covers you. Build when a customer, a billing rule or a second vendor needs data the catalogue does not expose in the shape you need.
Do I lose my fleet data if I switch from Samsara to Geotab?
You lose access to the vendor's copy when the contract ends. History you already pulled through the API into your own store stays yours. That is the strongest practical reason to put your own integration layer between the vendor and anything you build.
