What the Samsara and Geotab APIs actually let you build, their documented limits side by side, why one pushes and the other only polls, who should not build at all, and what to build first.
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.
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.
Send us the build. We will tell you honestly what needs fixing.
A senior engineer reads your actual code and sends back what is genuinely broken, what is fine, and what can wait. Free, within 48 hours, and no obligation follows it.
If your app has few users, takes no payments and stores no personal data, you probably do not need us yet. We will say so.
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.
CEO and co-founder of Geminate Solutions, a software and product development partner. He has led teams shipping custom web apps, mobile apps, SaaS platforms, and AI products that serve over 250,000 daily active users.
Tell us which vendor you run and what you are being asked for. A senior engineer reads the API against your request and writes back with what it will give you, what it will not, and whether you should build at all. No pitch, no commitment.
- Whether your vendor's API exposes the data your portal, rule or billing feature needs
- Webhooks, polling, or both, and what that means for the first month of work
- An honest answer if Fleetio, Zapier or the vendor marketplace already covers it
- The order to build in, and which piece protects your history if you ever switch
Get your free integration review
Drop your fleet s vendor and work email. We reply within 48 hours.
Frequently asked questions
Get a free 24-hour review of your website
Send us your website link on WhatsApp. Within 24 hours we tell you exactly what is costing you customers and what we would fix first. No obligation and no sales script.
4.9 rated · 50+ products shipped · 250K+ daily users served
Already built something, and it is starting to break?
Most teams that reach us have a working product and a growing list of things that scare them. We read the code first and tell you what actually needs fixing, including the parts that do not. Rebuilding from scratch is rarely the honest answer.
Lovable Backend Solutions: What You Have, Where It Ends
Lovable gives you a real backend, until it does not. The documented ceilings of the edge function model, the five signals your app has outgrown it, the three ways to add a custom backend without a rebuild, and the honest case for doing nothing yet.
AI App Builder: Which One to Pick, and What Breaks After
Every comparison ranks these tools on the demo. None say what you are left holding. What Lovable, Bolt.new, v0, Replit Agent, Base44 and Firebase Studio each generate, where no-code AI app builders differ from code-generating ones, and the four failures that show up the week real users arrive.
How Do You Stop Prompt Injection in a Production AI Agent?
Your system prompt telling the model to ignore injected instructions does not hold, and a classifier will not save you either. Where the trust boundary actually belongs, why closing the exit beats guarding the entrance, and the six published patterns that trade capability for a guarantee.
AWS IoT Core vs Azure IoT Hub: Does the Choice Matter?
Every comparison is a table of checkmarks. None say whether the decision deserves the three weeks you are about to give it. What each platform actually is, where lock-in really accumulates, what breaks first once the fleet is real, and when the right answer is to skip both.
React Web App to Mobile: Wrap, Rewrite, or Neither?
The tutorials say the wrap takes five minutes. They are right, and that is not the hard part. What ports out of a React codebase, what quietly does not, the App Store rule nobody mentions until after the work is done, and how to tell which of the three answers your product actually needs.
Can You Put PHI in an LLM? What a BAA Actually Covers
Every page tells you ChatGPT is not HIPAA compliant. None tell you what compliant looks like in your stack. Which vendors sign a BAA, what that signature reaches, why zero data retention decides whether it means anything, and the leak sitting in your own observability tooling.
Firebase Studio Is Shutting Down: Getting Your App Out Before March 2027
Google deletes Firebase Studio workspaces on 22 March 2027. Your data survives and your app keeps running. The record of why it was built the way it was does not. What the export contains, what it leaves behind, and what breaks first under real users.
Base44 to Production: What You Own and What You Cannot Take
You pressed export and got a repository. Then you read the environment file and found it still points at Base44. What the export actually contains, what stays behind, what the Wiz security disclosure means, and the four-stage sequence for moving off the platform.
Your AI Pilot Works. Why Is It Still Not Live?
The demo landed and the budget followed. Nine months later it is still a pilot. Why a pilot is a complete answer to a different question, what has to exist around the model before real users arrive, how to tell a retrieval problem from a generation one, and the order the work has to happen in.
FlutterFlow to Production: What Export Actually Gives You
You pressed Export Code and found out it only goes one way. Somebody has already said the word rebuild. It is real Flutter and it compiles, so this is almost never a rewrite. What actually lands in your repository, why the helper library is now yours to maintain, where custom code stops, and the order a takeover has to happen in.
Single Tenant to Multi Tenant: What Actually Has to Change
Fifteen customers on fifteen deployments, or one bespoke build you now want to sell as a product. Somebody has told you this needs a rewrite. It usually does not. Why the tenant column is the easy afternoon, why enabling row-level security does not apply it to the role that owns the table, and what breaks that is not the database at all.
Expo Go to Production: What Actually Breaks
It ran fine in Expo Go and now it will not ship. The JavaScript is not the problem and almost none of it needs rewriting. Why you no longer eject, why your environment variables were baked in at build time, what the New Architecture migration really costs, and who should not do any of this.
On-Premise LLM Deployment: Do You Actually Need It?
The data cannot leave our infrastructure is four requirements in one sentence, and only one of them needs your own hardware. What the cloud already guarantees by default, why strict retention quietly switches off specific frontier models, and the three cases where on-premise is genuinely the only answer.
Supabase Scaling: Which Wall You Actually Hit (2026)
Three walls, in a fixed order. Connection exhaustion first, query shape second, real architectural limits a distant third. Why upgrading compute is usually the wrong first move, why Prisma times out when nothing else does, and the three cases where leaving Supabase is genuinely the answer.
What Does Lovable Actually Generate? The Answer Changed in May 2026
Nearly every guide still says React on Vite. Lovable s own FAQ says apps created from 13 May 2026 use TanStack Start with server-side rendering. How to check which one your project is, why it decides whether AI crawlers can read you, and why you almost certainly do not need a Next.js rebuild.
Next.js 16 Migration: What the Codemod Cannot Do For You
The codemod renames middleware to proxy and moves your Turbopack config. It cannot decide where your auth boundary lives, and it will not stop next build failing on a webpack config you never wrote. What breaks, in what order, and who should wait.
Replit to Production: The Blast Radius Guide (2026)
Taking a Replit app live is not a code quality problem, it is an access problem. What the 2025 database deletion actually proved, what Replit fixed within a day, what still shares credentials with your agent, and who should not harden anything yet.
MCP Server in Production: What Changes When It Stops Being Local
Your MCP server works on STDIO. Exposing it over HTTP turns it into an internet-facing OAuth 2.1 resource server with a different threat model. What the spec actually requires, why token passthrough is forbidden twice, and who should not build this at all.
Originally published on Geminate Solutions.
Top comments (0)