What the integration surfaces are and which one to use for what. Full endpoint reference and credentials are issued with access rather than published, so this page cannot go stale.
| You need to… | Use | Why |
|---|---|---|
| Show live vehicle positions in your app | REST API | You control refresh rate and can request exactly the fleet you display |
| React when a vehicle enters a customer site | Webhook | Polling for it adds latency and wastes requests between events |
| Reconcile last month for invoicing | REST API or export | Bulk historical reads belong in a scheduled job, not an event stream |
| Keep an ERP continuously in step | Data forwarding | Purpose-built for a continuous feed into another system |
| Prove a journey in a dispute | Export | You want the underlying records, in a format that survives outside the platform |
| Migrate away from the platform | Export | Full history in an open format is the test of whether you truly own your data |
Published API reference drifts. Endpoints change, parameters are added, and a public page describing them is out of date within months unless somebody owns keeping it current — which, on a marketing site, nobody realistically does. Documentation that is confidently wrong costs an integrator more time than no documentation at all.
So the full reference travels with credentials, versioned alongside the API itself, and this page covers the part that does not change: what the surfaces are, which one fits which job, and what to ask for. If you want the reference, ask for access — there is no gate beyond being a customer or a partner building against it.
Three questions save integration teams weeks. What is the rate limit and what happens when you exceed it — a 429 you can back off from is very different from a silent drop. Are webhooks retried, and are they signed — without retries you need reconciliation logic, and without signatures you cannot verify the sender. What does the data look like at volume — a response shape that is pleasant for ten vehicles can be unworkable for five thousand, and that is better discovered in a sandbox than in production.
Every platform will tell you that you own your data. The operative question is whether you can get it out in a format you can use — a documented schema and full position history, rather than a summary report in a spreadsheet. We have said the same thing on the vendor checklist, and it applies to us as much as to anyone else: ask for a sample export before you sign, not after you want to leave.
Describe what you are integrating and we will issue sandbox credentials and the full reference. Request API access or message us on WhatsApp.
Yes — a REST API plus webhooks, issued to customers and partners with credentials and full reference documentation. We do not publish endpoint detail openly because it would drift out of date and because access is authenticated per account.
Both, for different jobs. Poll the API when you need current state — "where are these vehicles now", "give me last month's trips". Use webhooks when you need to react to something happening — a geofence breach, a harsh event, a completed delivery. Polling for events wastes requests and adds latency; webhooks for state is unreliable if you miss one.
Yes. Position history is exportable and readable through the API, in open formats. This matters more than it sounds: it is what makes leaving possible, which is why it is worth confirming with any platform vendor before you commit rather than after.
Yes. Data forwarding pushes device records onward to a third-party endpoint, which suits fleets who need telemetry inside an existing ERP or analytics stack. Tell us the destination format and we will confirm what is involved.
Yes, a staging environment with test credentials so integration work can start before a production account exists. Ask for it when you request API access.
Tell us what you are building and which system it has to talk to. We will issue sandbox credentials and the full reference.
Request API Access →