---
title: "Wialon API Token and Login: Sessions That Survive"
url: https://theassettrack.com/wialon-api/token/
description: "Wialon authorization end to end: the login form, token/login, token/update, the access-flag table, and the 100-day inaction rule that deletes idle tokens."
---

# Wialon API Token and Login: Sessions That Survive

Reference · last checked August 10, 2026

Wialon authorization end to end: the login form, token/login, token/update, the access-flag table, and the 100-day inaction rule that deletes idle tokens.

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://sdk.wialon.com/wiki/en/kit/remoteapi/apiref/login/login):

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

| Parameter | Description | Default |
| --- | --- | --- |
| `client_id` | App, site or client name the token is generated for | Site name (title) |
| `access_type` | Token flags | `0x100` |
| `activation_time` | Token activation time, UTC seconds; `0` means now | `0` |
| `duration` | Token lifetime after activation | — |
| `redirect_uri` | Where the result is returned | — |

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](https://sdk.wialon.com/wiki/en/kit/remoteapi/apiref/token/update):

| Value | Grants |
| --- | --- |
| `0x100` | Online tracking |
| `0x200` | View access to most data |
| `0x400` | Modification of non-sensitive data |
| `0x800` | Modification of sensitive data |
| `0x1000` | Modification of critical data, including messages deletion |
| `0x2000` | Communication |
| `-1` | Unlimited operation as the authorized user, including managing user tokens |

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](https://sdk.wialon.com/wiki/en/kit/remoteapi/apiref/token/login):

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

| Parameter | Description |
| --- | --- |
| `token` | The token, 72 symbols |
| `operateAs` | Subuser name to log in as (optional) |
| `fl` | Response flags |

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>}`

| Parameter | Description |
| --- | --- |
| `callMode` | `create`, `update` or `delete` |
| `h` | Token name, 72 symbols (for update and delete) |
| `app` | Application name — cannot be an empty string |
| `at` | Activation time, UNIX time; `0` means now |
| `dur` | Duration after activation, in seconds. Maximum 8,640,000 (100 days). `0` means infinite |
| `fl` | Access flags |
| `p` | Custom parameters; must be an object or array of objects, `"{}"` minimum |
| `items` | Item ids the token grants access to (optional) |
| `deleteAll` | For `callMode:delete`, deletes all created tokens |

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](https://help.wialon.com/en/api/remote-api/limitations). 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](https://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](https://web.archive.org/web/*/https://forum.wialon.com/*).

- 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.

## Also in this reference

- ### Wialon API Errors: Codes 1, 4, 6, 7 and 1004
 The full Wialon Remote API error table, the 1003 reason variants, the quotas that produce each code, and how to classify them for retry logic.
 [Wialon API Errors: Codes 1, 4, 6, 7 and 1004](https://theassettrack.com/wialon-api/errors/)
- ### Wialon API in Postman: Authenticate in 10 Minutes
 The Wialon request format, the two headers and encodings that break every first call, and a Postman setup for an authenticated session.
 [Wialon API in Postman: Authenticate in 10 Minutes](https://theassettrack.com/wialon-api/postman/)
- ### Wialon API: Get a Unit's Last Position and Message
 Data flags, core/search_items, and the difference between last position and last message — the distinction behind the most-asked question on the SDK board.
 [Wialon API: Get a Unit's Last Position and Message](https://theassettrack.com/wialon-api/units/)
- ### Wialon Drivers API: Bind Drivers to Units
 Create drivers, bind them to units, read binding history over the Wialon Remote API — including the avl_driver auto-binding sensor.
 [Wialon Drivers API: Bind Drivers to Units](https://theassettrack.com/wialon-api/drivers/)
- ### Wialon API Reports: exec_report Without the Errors
 One report per session, the cleanup_result rule, the calls that cannot run alongside it, and the time limit that returns no rows instead of an error.
 [Wialon API Reports: exec_report Without the Errors](https://theassettrack.com/wialon-api/reports/)
- ### Wialon API Notifications: Create, Edit, Enable
 resource/update_notification end to end — call modes, the trigger and action pair, schedules, and the response fields that make notifications diffable.
 [Wialon API Notifications: Create, Edit, Enable](https://theassettrack.com/wialon-api/notifications/)
- ### Wialon Retranslator: Protocols and Configuration
 The nine retranslation protocols Wialon can forward to, the update_config parameters each one uses, and where retranslation fits against an API pull.
 [Wialon Retranslator: Protocols and Configuration](https://theassettrack.com/wialon-api/retranslator/)