Wialon API: integrating GPS monitoring with your own systems

For the first few months after monitoring goes live, most companies find the web interface and the reports sufficient. Then questions of a different kind appear. The accounts department wants to see mileage in 1C next to the waybill. The sales team wants to know where the vehicle carrying a customer's order is, right there in the CRM record. The logistics team wants new runs from their system to reach the monitoring platform by themselves.

You can copy figures from one spreadsheet into another, but it is daily manual work and a source of errors. The right way is to let the systems talk to each other directly. Wialon has an open API for that, and we have experience of connecting it to the accounting systems used by companies in Azerbaijan.

If what you need is a link to one particular program rather than the API in general, have a look at the page on integration with ERP and CRM as well. This page is about the tools themselves and how the connection is put together.

Gurtam publishes the Remote API and SDK reference at sdk.wialon.com. The exact address of the server your integration talks to depends on where the account runs — we issue it together with the token so that developers are not left guessing.

Here is what getting started looks like, without tying it to any particular language:

• Logging in with a token. A request to the token/login service with a token parameter. The response is JSON with a session identifier (eid) and the user's details. That identifier is passed in the requests that follow.
• Finding objects. The core/search_items service with the type avl_unit returns the list of vehicles the token has access to, with a set of fields governed by flags: name, last message, sensors.
• A report. Running a report template for a period and receiving the rows of the table. This is usually how mileage and fuel are pulled into 1C.

Rights are set when the token is issued: read-only or control, which objects, how long it is valid. For an export into an accounting system, read access is enough. Rights to send commands to a tracker are issued separately and only where they are genuinely needed.

The platform returns errors in JSON in an error field with a numeric code. Here is the practical minimum of handling we ask you to allow for:

• an invalid session — log in with the token again and repeat the request;
• access refused — do not retry, tell the administrator: the token is short of rights or the object has been taken out of the group;
• invalid parameters — write the whole request to the log, this is a bug in the integration's code;
• a timeout or a server error response — retry after a pause rather than immediately in a loop, otherwise the integration will run into the limits.

The specific limits on request frequency and response size depend on how the server is configured. We discuss them at the start, before a developer writes something that polls every five seconds.

Let us show what a typical integration looks like from the inside. A drinks distributor delivers goods from a warehouse in Sumgait to shops around Baku and Absheron. The orders live in a CRM and the vehicles in Wialon, and until now those two worlds never met.

In the morning the CRM pulls the list of vehicles that have gone out on the road through the API and assigns route sheets to them. When a vehicle enters a shop's geofence, Wialon sends a webhook and the order in the CRM is set to delivered, awaiting confirmation. If the vehicle left the point in less than 3 minutes, the manager sees a flag and rings the customer back: the goods may not have been unloaded.

In the evening a separate request pulls the mileage and working time of each vehicle and puts them into the accounting system. Nobody moves anything by hand.

The difficulty here is not the code but the agreements: which status counts as delivered, what to do with points that have no coordinates, who is responsible if the CRM is unavailable. We talk those questions through with your team before development starts.