Wialon Hosting does a great deal: it tracks vehicles live, runs reports, raises alerts, and exposes an API that extends all of it far beyond the interface. Through the API you can read units, messages, events, and reports programmatically and build your own tools on top. Nearly all of that work is shaped around running a fleet day to day, and the platform is tuned to stay responsive under that load, however many people are leaning on it at once.
Extracting years of accumulated history is a different job. When you set out to pull every position report, every stop, and every fuel reading for a unit going back two years, you are asking for a bulk export rather than a live lookup or a routine report. The limits Wialon places on the API are entirely sensible for protecting day-to-day operations and the shared infrastructure everyone depends on. They simply become an obstacle the moment you want to move a long history into a PostgreSQL database of your own for analytics, compliance, or reporting.
This article walks through the limits that apply to extraction, explains why the most obvious approach runs straight into them, and describes the measured approach that stays within them.
The limits
Wialon Hosting documents a number of hard caps on API usage. A few of them directly affect how you design an extraction:
- No more than 10 API requests at the same time.
- No more than 3 resource-intensive requests at the same time (loading messages, running reports, and the like).
- A maximum of 400,000 rows in a single report.
- A 10-minute timeout for the continuous execution of reports for one user from one IP; exceed it and you cannot request reports again for 10 minutes.
- No more reports per hour than the system is able to execute in that hour.
- No more than 100 active sessions for one user from one IP at the same time.
- No more than 1,000 active tokens per user, deleted automatically after 100 days without use.
For bulk extraction, three of these drive the design: the 400,000-row ceiling on any single report, the 10-minute execution timeout with its subsequent cooldown, and the cap of three concurrent resource-intensive requests.
Why the obvious approach struggles
Imagine you have two years to retrieve — January 2025 through July 2026, across fifty units — and you ask for it the most direct way you can.
A single request for everything belonging to one unit over the full two years will almost certainly be refused, because two years of telematics for an active vehicle runs to several million records, far beyond the 400,000-row limit. The natural next step is to break the request into months, but that brings its own difficulties. Some months will fall comfortably under the ceiling while busier ones will exceed it, and you have no way of knowing which is which until the request either succeeds or fails. Sending all twenty-four monthly reports at once is no better, since that many concurrent resource-intensive requests sit well above the limit of three and will be rejected.
You can, of course, throttle the work to three reports at a time and wait for each batch to finish before sending the next. That keeps you inside the concurrency rules, but the extraction slows considerably: fifty units across twenty-four months is twelve hundred reports, and you are still relying on month boundaries that may quietly exceed the row cap. Should a run of heavier reports push your cumulative execution past ten minutes, the platform will lock you out of reporting for a further ten, and across a large history you are likely to meet that cooldown more than once.
A measured approach that respects the limits
FleetSQL, and any tool built thoughtfully for this purpose, addresses the problem with three straightforward principles: keep each unit of work small and predictable, limit how much runs at once, and pace the whole effort to the budget the platform allows.
The foundation is to extract one day for one unit at a time. Rather than requesting a month of a unit’s data and hoping it fits, you ask for a single calendar day, which for one vehicle is almost never anywhere near the 400,000-row ceiling, even on a busy day. A day is also a natural and honest boundary, and aligning it to each unit’s own timezone and daylight saving rules means you neither lose nor double-count records around a clock change. Two years across fifty units becomes roughly 36,500 of these small daily jobs, each one modest and entirely predictable in size.
Concurrency is then handled by keeping a pool of in-flight requests capped at two or three resource-intensive jobs, comfortably within the limit, and refilling it as each job completes. This is a semaphore in the ordinary sense, a standard and well-understood pattern. Because every job is small it also finishes quickly, staying well clear of the ten-minute timeout, so the cooldown that interrupts a careless extraction never has cause to trigger.
Working day by day has another advantage: every unit-day stands on its own. When a data-quality check turns up a single bad day, you re-pull only that day. When a new unit appears in the account, you backfill its history from the beginning without touching anything else. When a compliance request asks for the last ninety days again, you queue ninety daily jobs for that unit. If something goes wrong, you redo the day it affected and leave the rest alone.
In practice this runs faster than the job count suggests:
One day across ~1,000 units — roughly 20,000 rows across three tables — completes in a few minutes. A backfill of ~500,000 rows finishes in under two hours, and it runs unattended.
How long any particular pull takes depends on how many days you ask for and how busy the units are.
Bringing it together
None of this removes the underlying effort. You still need to understand the API flows — units, resources, their properties, events, and reports — handle the retries that any long-running job eventually needs, and build the pacing and concurrency controls that keep you within the rules. The requirements are clear once you have mapped them, and they stay the same from one extraction to the next.
The limits were never really the problem. The trouble comes from asking for the data in a way that ignores them. When you approach the export the way the platform expects — small, predictable jobs, paced gently and run a few at a time — moving years of history out comes down to patience. You invest the effort once, and what remains afterwards is a complete history living in a Postgres database you own — typed, queryable, and free of the limits you just worked around, whether the thing asking the questions is a dashboard, a BI tool, or an LLM that speaks SQL.
If you are still weighing whether to do this by hand, build your own pipeline, or lean on a tool, the companion guide on why and how to extract your Wialon fleet data covers those trade-offs in full. FleetSQL carries out the chunking and pacing described here and delivers the data directly into PostgreSQL.
