Getting your data out

A dashboard is a fine place to look at your fleet. It is a terrible place to keep it.

The numbers we generate — machine hours, utilization, service history, geofence events — only earn their keep when they reach the systems where decisions actually get made: the accounting package that bills the job, the maintenance system that orders the parts, the spreadsheet the owner opens on a Sunday night. If that data lives only behind our login, it’s stranded. Nicely visualized, and stranded.

So the question a careful buyer asks — “can I get my data out?” — is the right question. Here’s our answer, in the order you should reach for it.

Three ways out, lightest first

Most teams over-engineer this. Reach for the simplest mechanism that solves the problem and stop there.

1. Export. The boring one nobody brags about and everybody needs. A CSV of hours-by-asset for the month, a service-history dump for the audit, a scheduled report that lands in an inbox every Monday. No engineering on your side, no integration to maintain. If all you need is the month’s numbers in a spreadsheet, you do not need an API — you need an export, and you should be able to get one without calling us.

2. API. When you want the data on your schedule, in your own system, without a human in the loop. A REST API you pull from — give me every asset’s hours since this timestamp — and webhooks we push to you when something happens: an order completed, a geofence crossed, a threshold tripped. Pull for state, push for events. Most integrations need both.

3. Direct integration. Into a system you name — the ERP, the CMMS, the BI warehouse. This is the heaviest option and the last one you should want, because it’s the most to build and the most to break. Sometimes it’s genuinely the right call. Often the API plus a small script you control is less fragile than a bespoke connector you depend on us to maintain.

What “good” looks like on the way out

The mechanism matters less than the shape of what comes through it. Data you can’t join to your other systems is just a prettier dead end. A few things we hold ourselves to:

• Your IDs, not ours. Every record carries your fleet number, not just our internal asset ID. If the data comes out keyed only to identifiers that mean nothing in your accounting system, you can’t join it, and an un-joinable export is a screenshot with extra steps.
• Unambiguous timestamps. UTC, with timezone, in a documented format. Fleet data spans sites and seasons; “3:00” without a zone is the start of a reconciliation fight, not the end of one.
• A documented, versioned schema. You should know what every field means and trust that we won’t rename it under you next quarter. When the shape has to change, it changes behind a version, not silently in your Tuesday import.
• Deltas, not just dumps. You should be able to ask for what changed since last time instead of re-pulling the whole fleet every run. Full dumps are fine at ten assets and miserable at a thousand.

These aren’t features. They’re the difference between a data export and a data source.

What we don’t pretend to be

The honest list, as ever — the things we deliberately don’t do on the way out.

• We’re not your system of record for money. We’ll hand the accounting system clean hours and events. We don’t price the job, cut the invoice, or try to be the ledger. That’s a different system and we’d rather feed it than fake it.
• We won’t build a connector for every ERP on earth. We give you a documented API and the docs to use it, plus integrations into the systems enough customers actually run. A one-off bespoke pipe into a niche package is a maintenance liability we’d be doing you no favor by promising.
• The API serves processed numbers, not the raw firehose. Hours, utilization, events, history — the curated layer. The raw per-packet BLE stream is a different volume-and-cost conversation entirely; we keep that pipeline boring precisely so the numbers that come out the other end are clean. If you genuinely need the raw feed, that’s a deliberate decision, not a default endpoint.

A word on whose data it is

It’s yours. That shouldn’t need saying, but in this category it does, because “can I get my data out?” is so often really asking “if I leave, am I hostage?” You shouldn’t have to read a contract to find out. The export exists, the API exists, and they exist on the way out as readily as on the way in. A platform that makes leaving expensive is telling you something about how confident it is you’ll want to stay.

What we recommend

1. Decide where the data needs to live before you deploy. “Into the maintenance system and the CFO’s BI tool” is an answer you want on day one, not after you’ve built a habit of exporting by hand.
2. Reach for the lightest mechanism that works. Export before API, API before a custom integration. Every step up in power is a step up in what you have to maintain.
3. Key everything to your own asset IDs. Decide your canonical fleet numbering and make every system speak it. This is the same identity discipline that makes onboarding go cleanly, and it pays off at every join forever.
4. Pull deltas, push events. Ask for what changed, not the whole world, and let webhooks tell you when something happened instead of polling for it. Your integration stays cheap as the fleet grows.
5. Test the way out during the trial, not the exit. Pull a real export, hit the API once, before you’ve committed. The time to confirm you can leave is while you still easily can.

The point of getting your data out isn’t distrust. It’s that fleet data is only worth collecting if it reaches the place a decision gets made — and that place is almost never the dashboard you collected it on.

---

If you’re scoping how Fleet data needs to flow into the systems you already run, talk to us — we’ll walk through exports, the API, and which integrations are worth building versus scripting yourself.