Wialon API Token and Login: Sessions That Survive

Wialon authorization has two parts that are easy to conflate. A token is a long-lived credential carrying a fixed set of access flags, and a session is what that token buys for the duration of a run. Most integration failures in this area come from asking for the wrong flags at creation time, or from assuming that a token nobody deleted is still alive. This page covers the authorization form, token/login, token management through token/update, the full access-flag table, and the two defaults that cause the most trouble in production.

Ask for the access you need, not the access the form defaults to

The old core/login endpoint was valid only until 1 October 2015. The current scheme is oAuth-like: you send the account owner to a form on their own host, they approve, and a token comes back. The form takes a set of optional parameters, documented in New authorization way:

https://{host}/login.html?client_id=...&access_type=...&activation_time=...&duration=...&lang=...&flags=...&user=...&redirect_uri=...&response_type=...&css_url=...

That default is the single most consequential value on this page. 0x100 grants online tracking and nothing else, so a token minted from a form that never set access_type cannot read most data, and every data call it makes returns error 7 for the life of the token. The failure is confusing because it is not intermittent and not related to the request being made — the same call works for a colleague whose token was created differently.

Read the flag table before you send a customer to the consent screen

Access is granted as a combination of flags, and the full set is documented on the token management page:

A read-only integration wants 0x100 combined with 0x200, and there are two things to say about writing that down. The request format states that JSON does not support HEX values and that DEC must be used, so 0x300 goes into a request as 768 rather than as the hexadecimal string the documentation prints. And -1 grants everything, including the ability to manage the user’s other tokens, which means an integration requesting it in order to display a dashboard is asking a customer to approve full control of their account for a read-only feature. Wialon’s consent screen tells the account owner what is being requested, so the request is visible at exactly the moment a security-conscious buyer is deciding whether to proceed. Asking for 768 removes the conversation entirely:

https://{host}/login.html?client_id=Your%20App&access_type=768&duration=2592000&response_type=token

Exchange the token for a session

Once a token exists, token/login turns it into a session. The command is documented in the token login reference:

svc=token/login&params={"token":<text>,"operateAs":<text>,"fl":<uint>}

The response flags control how much the login response carries rather than what the session can do: 0x1 basic info, 0x2 user info, 0x4 token info, 0x8 items info, 0x10 billing services info, and 0x20 user custom properties. In decimal, like everything else. One constraint is worth knowing before debugging a login that fails for no visible reason — you cannot log in under a token that has not been activated, which is controlled by the activation time set when the token was created.

Treat the 100-day inaction rule as a design constraint

Tokens can also be created, edited and deleted programmatically. The token/update command manages your own tokens and those of users you have access to, and it is not an authorization method:

svc=token/update&params={"callMode":<text>,"userId":<text>,"h":<text>,"app":<text>,"at":<uint>,"dur":<uint>,"fl":<uint>,"p":<text>,"items":[<long>],"deleteAll":<bool>}

The reference states one rule in a single line that has broken more production integrations than the rest of this page combined: a token is deleted automatically through 100 days of inaction, even when dur is set to 0. Two consequences follow. Setting an infinite duration does not produce a permanent credential, because an unused infinite token still disappears on the inactivity clock. And the maximum explicit duration is also 100 days, so no token survives beyond that window without renewal either way. The documentation does not define what counts as activity, which makes the defensive posture a periodic token/login comfortably inside the window — it costs one call, it resets whatever the clock is actually measuring, and it doubles as a liveness check that surfaces a dead credential during business hours rather than at three in the morning when a nightly job fails.

Give every worker its own token

The pattern that keeps appearing in production systems is a single long-lived token, hardcoded, shared by every worker in the pool. It is convenient right up to the moment the token is revoked, expires, or crosses the inactivity line, and then every worker fails at the same instant — which is the hardest possible failure to diagnose, because nothing in the application changed and the logs show a uniform wall of error 1 across processes that have nothing else in common.

A token per worker, refreshed proactively on a schedule rather than reactively on failure, converts a fleet-wide outage into one worker’s problem and makes the failure legible. Keep tokens in a secrets manager rather than in environment variables or configuration files, rotate on a schedule rather than after an incident, and log every authorization event so the lifecycle is reconstructable afterwards.

The session quotas make the alternative actively dangerous rather than merely fragile. No more than 10 failed logins from one IP address are permitted in a minute, no more than 120 successful ones, no more than 100 active sessions of one user from one address, and no more than 1,000 active tokens per user, per the current limitations reference. That last one bounds the per-worker pattern from above: a token per worker is right, a token per run is not, because a job that mints a fresh credential on every execution will fill the allowance and then start failing to create them. Exceeding the login limits produces a temporary IP-address block, which is the mechanism behind the most common self-inflicted outage in this ecosystem: a worker receives error 1, re-authenticates, receives error 1 again because the token itself is gone, and loops. Ten iterations later the address is blocked and every other integration behind the same egress stops working too. Two rules prevent it — cap re-authentication at one attempt per request, and treat a failed token/login as terminal rather than as something to retry.

The Custom SDK development board on the Wialon forum held 485 topics of exactly this material before the board was taken offline. Every URL now redirects to the help.wialon.com root, sdk.wialon.com still links developers to it, and captured pages survive for roughly 61% of threads in the Wayback Machine.

• Request 768 for read-only integrations, and reserve -1 for tooling that genuinely manages tokens.
• Write flag values in decimal — the documentation prints hex, the API rejects it.
• Refresh each token well inside 100 days whether or not the integration has work to do.