Wialon developer documentation is spread across three properties, one of which has formally deprecated itself while remaining the most complete reference available, and one of which no longer exists at all. Anyone starting an integration loses time to that arrangement before writing a line of code, because following a link from the SDK to a discussion now lands on a homepage. This page is the map: what lives where, which of it is still authoritative, and the account-level constraints that bound every project regardless of how well it is written.
Take every number from help.wialon.com, and everything else from the SDK
The SDK’s API Reference index carries a line at the top stating that the documentation is no longer supported and directing developers to help.wialon.com/en/api instead. That line is easy to dismiss, because the SDK is still the deeper reference for commands and their parameters and the successor has not replaced that depth. Dismissing it is a mistake anyway, because the two sites have drifted and they no longer agree.
The gap is in the limits. The current limitations page documents constraints the SDK’s equivalent never mentions: a ten-minute ceiling on continuous report execution for one user from one IP address, after which reporting is locked out for a further ten minutes; a cap of 1,000 active tokens per user; a 2 GB limit on messages returned per request; 50 message layers; 30 core/check_unique calls per minute; and 9007199254740991 as the largest integer that survives a double parameter. An integration sized against the SDK’s numbers alone will meet at least one of those without knowing it exists.
So the working rule is to split the two sources by what they are good at. Anything metered — quotas, ceilings, timeouts, cooldowns — comes from help.wialon.com. Command shapes, parameters and response formats come from the SDK, where the pages that hold up are the request format page defining the POST-only, form-encoded shape every call takes along with the rule that JSON accepts no HEX values, the errors page holding the full code table, and the new authorization way and tokens pages describing the current auth scheme, which replaced core/login — valid only until 1 October 2015 and still occasionally found in sample code.
Read the account restrictions before promising a retention window
The developer section on help.wialon.com is the maintained one, but the constraint that most often derails a project sits on the user-facing side rather than the developer side. Wialon Hosting keeps unit history for 400 days by default: the help centre states that all messages older than the history period are automatically removed from the database, and that the period is extendable by request to a Partner Success Manager.
That single default bounds every analytics project built on Hosting. A dashboard comparing this quarter against the same quarter two years ago cannot be built from the platform alone, and the missing data was not lost through anyone’s mistake — it aged out on schedule. Because the period is a per-account value rather than a platform constant, find out what a specific account is actually set to before committing to a retention window in a proposal, and treat the answer as something that can change underneath the integration.
Expect no successor to the forum
The forum at forum.wialon.com held 17,322 topics and 187,588 posts across 39,785 registered users, including a board of 485 topics dedicated to custom SDK development. Every URL on it now redirects to the help.wialon.com root rather than to a matching page, which is the pattern Google’s own site-move guidance warns may be treated as a soft 404, and exact-title searches for archived threads return nothing. The SDK site still links developers there, so following an SDK link to a discussion lands on a homepage with no indication that anything is missing.
No successor discussion venue is linked from either documentation site. Questions that used to draw an answer within a day now have nowhere to go, which is the practical reason this reference exists. The Wayback Machine is the only surviving copy, with captured pages for roughly 61% of threads, and the archived board indexes preserve view counts — a reasonable proxy for what practitioners actually struggled with:
| Views | Thread |
|---|---|
| 17,549 | WebServices or connection to database |
| 11,747 | Geofence export data doesn’t have info |
| 11,544 | Integration to ERP knowledge |
| 6,599 | SAP Integration |
| 3,876 | ERP and WMS integration |
Integration and data export dominate that list, which is the gap these pages are written into.
Start with authorization, because most failures begin there
The token and login page covers the authorization form, token/login, token/update and the full access-flag table. Two defaults on it cause more trouble than the rest of the API combined: access_type defaults to online tracking only, so a token created without setting it cannot read data, and a token is deleted automatically after 100 days of inaction even when its duration is set to infinite.
The Postman page covers the request format in practice — the form-encoded body, the obligatory Content-Type header, decimal flag values, and an environment that holds a session without re-authenticating by hand. It is the fastest way to confirm that a credential works before any code exists.
Read the error table before writing retry logic
The errors page holds the complete code table, the five reason variants hiding behind code 1003, and a classification of which codes to retry, which need re-authentication, and which belong in a dead-letter queue on first sight. It also covers the published quotas behind codes 10, 1003, 1004 and 1005, and the report failure mode that returns no rows rather than an error — an absence that an ETL will happily write into a warehouse as a zero.
Work through units, reports, notifications and retranslation
The units page covers the data-flag table, core/search_items, and the distinction that made this the most-asked question on the SDK board: pos is the last known position, lmsg is the last known message, and a device reporting without a GPS fix updates one and not the other.
The reports page covers the rule that a session holds exactly one report result, so report/cleanup_result precedes every execution, along with the eight calls that cannot run alongside report execution and the interval flags that make a scheduled report irreproducible if chosen carelessly.
The retranslator page covers the nine protocols Wialon can forward to, which configuration parameters each one accepts, and where a push stream beats an API pull — along with the duplicate handling that running both paths makes mandatory rather than optional.
The notifications page covers resource/update_notification across its four call modes, the trigger and action pair, and the checksum field that lets an integration detect a customer editing a rule in the interface behind its back.
Architecture questions sit outside a reference and are argued at length elsewhere on this site: rate limits and resilient sync design, moving Wialon data into PostgreSQL, integrating Wialon with an ERP, and running Flespi and Wialon as a dual stack.