huawei-lte-api: talking to Huawei LTE routers over their web interface

The interface it wraps and why that matters

huawei-lte-api is described as an API for Huawei LAN and WAN LTE modems, and the readme spells out the use case: you can use this to simply send SMS, get information about your internet usage, signal, and tons of other stuff.

The important word is LAN. These are consumer and small-office CPE devices, a Huawei router sitting on your desk with an administration web interface, and the library drives the same HTTP endpoints that interface uses. It is a client for an undocumented vendor API, not a supported protocol with a specification behind it.

That single fact explains most of the project's shape, including the device list and the failure warnings. The readme enumerates what it has been tested on: nineteen 3G and LTE routers including the B310s-22, B525s-23a, B715s-23c, B818-263, E5180s-22, E5577Cs-321 and SoyeaLink B535-333, six 3G and LTE USB sticks including the E3131, E3372, E3531 and E5530As-2, and three 5G routers, the Huawei 5G CPE Pro 2, the 5G CPE Pro and the 5G CPE6. The author adds that it will probably work for other Huawei LTE devices too.

And then the will NOT work section, which is short and specific: the Huawei B2368-22 and the B593s-22, both because of incompatible firmware, with a testing device needed. The library is at version 2.0.0, released on 2026-08-13, and the last push was on 2026-08-14. The previous releases were 1.11.0 in March 2025 and 1.10 in August 2024, so the 2.0 major came after a long gap and the tree is essentially at the release.

The topics list is short, api-client and huawei, and the primary language is Python. The package declares itself as Production/Stable with Python 3.9 through 3.14 classifiers.

Installing it, from pip or from the author's own repositories

The package is on PyPI under the name huawei-lte-api:

pip install huawei-lte-api

But the readme also points at three distribution repositories maintained by the author, and that is the interesting part of the install section.

For Debian and derivatives, the key is fetched and installed into the system keyrings, and the source is added with a signed-by directive:

wget -O- https://repository.salamek.cz/deb/salamek.gpg | sudo tee /usr/share/keyrings/salamek-archive-keyring.gpg
echo "deb     [signed-by=/usr/share/keyrings/salamek-archive-keyring.gpg] https://repository.salamek.cz/deb/pub all main" | sudo tee /etc/apt/sources.list.d/salamek.cz.list

and then the package installs with apt update and apt install python3-huawei-lte-api.

For Arch, the repository block is added to the end of /etc/pacman.conf:

[salamek]
Server = https://repository.salamek.cz/arch/pub/any
SigLevel = Optional

and the package installs with pacman -Sy python-huawei-lte-api. The SigLevel setting of Optional is worth noticing, because it means the packages are not verified by signature, only by the https transport.

For Gentoo, the emerge command is emerge dev-python/huawei-lte-api.

Why run your own repositories at all? The readme does not say, but the practical reason is that the upstream PyPI package lags when the author wants a new release or a fix, and a self-hosted repository with the same versioning lets the package be installed and upgraded through the system's own package manager, which is what a homelab operator tends to want. The cost is that you are trusting one person's repository rather than PyPI, and the archlinux/ directory in the repository listing is where that packaging lives.

The Client and Connection API

The usage example shows the two-object structure, and the comments in it are more informative than the code.

from huawei_lte_api.Client import Client
from huawei_lte_api.Connection import Connection

# with Connection('http://192.168.8.1/') as connection: For limited access, I have valid credentials no need for limited access
with Connection("http://admin:[email protected]/") as connection:
    client = Client(connection)  # This just simplifies access to separate API groups, you can use device = Device(connection) if you want

    print(client.device.signal())  # Can be accessed without authorization
    print(client.device.information())  # Needs valid authorization, will throw exception if invalid credentials are passed in URL

The Connection object holds the session and the base URL, and the credentials go in the URL as basic auth. The comment about limited access makes the point that you do not need the superuser password if the device supports a lower-privilege account, and the device group under the client is described as simplifying access to separate API groups.

The two calls differ in an important way. client.device.signal() can be accessed without authorization, while client.device.information() needs valid authorization and will throw an exception if the credentials in the URL are invalid. That distinction matters for a monitoring setup, because you can poll signal strength on a router you have read-only access to.

The results come back as plain dictionaries, and the example shows the shape for information():

{
    "DeviceName": "B310s-22",
    "SerialNumber": "MY_SERIAL_NUMBER",
    "Imei": "MY_IMEI",
    "Imsi": "MY_IMSI",
    "Iccid": "MY_ICCID",
    "Msisdn": None,
    "HardwareVersion": "WL1B310FM03",
    "SoftwareVersion": "21.311.06.03.55",
    "WebUIVersion": "17.100.09.00.03",
    "MacAddress1": "EHM:MY:MAC",
    "MacAddress2": None,
    "ProductFamily": "LTE",
    "Classify": "cpe",
    "supportmode": None,
    "workmode": "LTE",
}

The dict includes the identifiers that a device owner needs and that a monitoring system wants to log, the IMEI, IMSI and ICCID, plus the software and web interface versions. The SoftwareVersion field is the one that matters most for compatibility, since it is the firmware version and therefore the thing that determines whether a given API call works.

The readme points out that for more API calls you should look at the code in the huawei_lte_api/api folder, because there is no separate documentation yet. That is a real characteristic of the project: the API surface is discoverable by reading source rather than from a reference.

What the examples directory shows is possible

The examples folder is the practical documentation, and the file names describe the range of what the library can do to a router.

There are send_sms.py and read_sms.py, which are the headline capability, and send_ussd.py for the code-based requests that mobile networks use for balance checks and the like. There are device_info.py and device_signal.py for the queries, data_dump.py to pull a full dump of what the device exposes, and get_filtered_devices.py to enumerate available devices.

Then there is the router control set: reboot.py, net_mode.py to switch between network modes, toggle_wifi.py, toggle_telnet.py, reconnect_dialup.py, create_dialup_profile.py, mac_filter.py and initial_setup_e5576-320.py, which is a script for the initial configuration of one specific model. There are also connect_with_proxy.py and ignore_ssl_check.py, the latter being relevant because these devices present a self-signed certificate on their administration interface.

Beyond the library, the readme lists community projects built on it, which is a decent indication of the real use cases. Monitoring traffic and signal, set band with signal level and bandwidth shown for the B525s-23a, an application that monitors internet connectivity and restarts the router when the internet is not reachable, and a monitoring app with a TUI interface in the style of htop. On the SMS side, one project relays received SMS into email.

That list is the strongest argument for the library. The restart-when-unreachable case is the kind of small automation that the router's own web interface cannot do and that a shell script using the undocumented API can, and it is a plausible reason to depend on an unsupported interface at all.

There are also ports to other languages, a TypeScript and JavaScript port and a PHP port, listed with their repositories. Those are separate projects by other authors, so they may lag the Python version, and the readme does not say they track it.

Where huawei-lte-api is the wrong choice

The first limitation is that the API is undocumented, so nothing guarantees it stays the same. The library talks to endpoints that Huawei shipped for its own web interface, and firmware updates can change the response format or the endpoint path without notice. The two models the readme says will not work, the B2368-22 and the B593s-22, are exactly that failure mode, and the readme attributes it to incompatible firmware.

The second is the device specificity. There is a list of tested hardware, and anything outside it is a guess. The author says it will probably work for other Huawei LTE devices too, which is honest but not the same as supported, and a USB stick has an extra condition attached: the device must support NETWORK mode, the HiLink version, and it will not work with serial mode. That is a constraint that catches people out, because a USB stick that works with one tool and not another is often a mode setting rather than a broken device.

The third is the security posture the usage example teaches. Credentials go into the URL as admin with a password, over plain http to a device address on the LAN. That is how the device's own interface works, so the library inherits it, but any script that logs the URL, puts it in a process listing or proxies it will leak the router administrator password. The example's own comment says MY_SUPER_TRUPER_PASSWORD, which is a hint that the device has a single superuser account, and on many of these routers it is. There is an ignore_ssl_check.py example, which shows the same pattern on the TLS side.

The fourth is that the API surface is undocumented even by the project. The readme says there is no separate documentation and points you at the source of the api folder, so learning the available calls means reading Python. That is workable for the common calls and slow for anything unusual.

The fifth is the release rhythm. Versions 1.10, 1.11.0 and then 2.0.0 arrived over roughly two years, with the major bump in August 2026 after a long quiet period. The project is classified as Production/Stable, which is a fair description of how the library behaves with hardware it supports, but it is also a single-maintainer project with the sponsorship request in the readme as the mechanism for keeping it going.

Editorial conclusion

huawei-lte-api fits a homelab or monitoring project that needs data from a specific Huawei router model, since the library wraps the router's own HTTP interface and the readme lists nineteen tested LTE routers, six USB sticks and three 5G CPE devices. It is the wrong choice if you need a supported, guaranteed interface, because the API is undocumented and the readme itself lists two router models that will not work due to incompatible firmware. Before adopting it, confirm your exact model is on the tested list, check the entries for the two devices marked as needing a testing unit, and note that the library is LGPL-3.0 with version 2.0.0 released on 2026-08-13 and the last push on 2026-08-14.

Frequently asked questions

Official sources

1. Issues
2. License: LGPL-3.0
3. README
4. Releases
5. Salamek/huawei-lte-api on GitHub