# Steamauto automates the item trading that happens on Chinese game marketplaces

> Steamauto is a Python program that connects to the Chinese game item marketplaces, NetEase BUFF, YouPin, ECOsteam and C5Game, and performs the repetitive half of trading: accepting delivery offers, relisting items, adjusting prices and keeping listings in sync across sites. It is AGPL-3.0 licensed, configured through JSON5 files, and it is explicit about the credentials you must not leak.

**Steamauto/Steamauto** — 免费开源的网易BUFF、悠悠有品、ECOsteam、C5Game、Steam的全自动收发货解决方案

- Repository: https://github.com/Steamauto/Steamauto
- Stars: 1,305 · Forks: 183
- Language: Python
- License: AGPL-3.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/steamauto-steamauto

## Five platforms, one configuration file

Steamauto is an open source, free to use solution for automatic selling and delivery across the Chinese game item marketplaces, and the feature table in the readme lists what it covers per platform and which setting turns each part on.

For NetEase BUFF it handles the delivery type quotes automatically and can also raise seller quotes for CS2, controlled by buff_auto_accept_offer. For YouPin it does automatic delivery, automatic listing for rental items, automatic listing for sale and automatic price changes, with uu_auto_accept_offer, uu_auto_lease_item and uu_auto_sell_item. ECOSteam gets automatic delivery plus synchronised selling and rental listings with BUFF and YouPin, under the ecosteam setting. C5Game gets automatic delivery with c5_auto_accept_offer. Steam itself gets local acceleration and automatic acceptance of gift offers that do not spend any Steam inventory, with steam_local_accelerate and steam_auto_accept_offer. And there is a single notification service that pushes login, delivery, failure and report events, called notify_service.

The last row is the one that is unusual. Every other feature is a marketplace integration, and notifications are the layer that makes the automation observable, which matters for a tool that acts on your behalf while you are not looking.

The implementation is Python, the licence is AGPL-3.0, and the last push was on 2026-10-05. The releases are named by their build date, 20261005-1020, 20261001-2119 and 20261001-2111, so there is no semantic version to reason about and the build you run is identified by when it was made.

## Running it, from a release or from source

The readme gives two routes, and the release route is the one most people will take.

You go to the GitHub releases page, download the build that matches your system, and run the program once. That first run generates config/config.json5 and config/steam_account_info.json5. You then edit config/config.json5 to enable the plugins and platform features you want, and edit config/steam_account_info.json5 with your Steam login information and token parameters. Running the program again completes the BUFF and YouPin logins when it prompts for them.

The source route is three steps.

```bash
pip install -r requirements.txt
```

```bash
python Steamauto.py
```

Running it once creates the configuration files, and then you fill them in as in steps three to five of the release route.

The readme is emphatic about two things before any of that. It asks you to read the document carefully, and it asks you not to violate the open source licence, including but not limited to reselling the program closed source or modifying it and not releasing the changes. For an AGPL project whose users are running it with their own account credentials, that request is not decorative, and it is a reasonable thing for the author to insist on.

## Notifications run through Apprise, and they can be filtered

The notify_service configuration is the current unified notification setup, and it is not limited to the BUFF plugin. The notifier uses the Apprise format and supports Telegram, DingTalk, Feishu, WxPusher, Server Jiang and others.

Using Apprise as the delivery layer is a good choice for a tool like this, because it means the notification targets are configured as service URLs rather than as code, and adding a channel does not mean touching the project.

The four settings are worth reading, because two of them are about what you do not want to hear about.

notifiers is the list of notification servers, filled in with Apprise format addresses, and if it is empty no notifications are sent. custom_title overrides the default title of the message, and if it is empty the default is used. include_steam_info controls whether the Steam account information is included in the notification, which for a shared screen or a push notification on a personal phone is a privacy decision rather than a display option.

And blacklist_words is a list of words that suppress the notification, so a notification whose content contains any of them is not sent. That is a filter for the case where the automated tool would otherwise report something you would rather not be pinged about, such as a market event that includes a name you do not want on a lock screen.

## The repository is a folder per marketplace

The top level listing is the architecture of the integration layer, and it is organised by platform.

There is BuffApi/ for the NetEase BUFF interface, PyC5Game/ and PyECOsteam/ for the two platforms that have their own Python client packages, and uuyoupinapi/ for YouPin. The plugins/ directory holds the pieces that turn the platform APIs into the features in the table, so a feature such as automatic delivery is a plugin and not a platform client.

Then there is steampy/, a Steam client library, and utils/ for the shared helpers. The protobufs/ directory and the public.json file suggest a protocol buffer layer, which is how a marketplace that speaks a binary protocol rather than JSON is handled. build.spec is the PyInstaller specification for building a single file executable, which is what the release downloads are.

The build and packaging files are modern. There is a pyproject.toml with a pdm-backend build system, a pdm.lock for the resolved dependencies, a ruff.toml for the linter configuration, and a .git-blame-ignore-revs file, which is the convention for when a bulk reformat commit should be ignored by the blame view.

The dependency list in the project file is worth reading for what it says about the implementation. There is requests for the HTTP calls, apprise for the notifications, colorama and colorlog for the terminal output, json5 for the configuration format, beautifulsoup4 and chardet for parsing the HTML responses that some of these sites return, rsa and qrcode for the key handling, PyCryptodome for the crypto, protobuf for the protocol buffers, PySocks for the proxy support, schedule for the periodic jobs, pytz for the time zones, pydantic for the model validation, requests-toolbelt for the multipart uploads, and tqdm for the progress bars.

## The credentials are the whole risk surface

The security section of the readme is short and specific, and it is the part to internalise before running the tool.

Do not publish config/steam_account_info.json5, config/buff_cookies_*, config/uu_token_* or config/rsakey.txt. Do not post screenshots or logs that contain account names, passwords, tokens, cookies or private keys in a public issue. The log files are in logs/, and when you hit a problem you should look at the newest log first, and remove sensitive information before opening an issue or asking in the group chat.

That list is effectively the attack surface of the tool. It holds your Steam account credentials and token, the cookies that let the program act as you on BUFF, the YouPin token, and an RSA private key for the ECOSteam platform. A leak of any one of them is an account problem, not a configuration problem.

The FAQ addresses account security directly. The source code is open on GitHub so anyone can read it, and on the assumption that your own machine is not compromised the account cannot leak. The rest of the answer is the sensible half: keep the local configuration, cookies, tokens, private keys and logs to yourself.

The ECOSteam setup makes the key handling concrete. You register for the open platform, request an identity, and provide an RSA public key to get the identity ID, and the RSA private key goes into config/rsakey.txt, which the readme says you should generate yourself, with a 2048 or 4096 bit key, and it notes that ECOSteam now supports the full key format rather than only the part without line breaks.

## Packaging, proxies and running several copies

Three practical details in the FAQ are worth carrying into a deployment.

The first is the proxy problem. If running from source with the proxies configuration gives a proxy error while the local proxy works, the readme says the error appears with a particular urllib version and that installing a specific version solves it.

```bash
pip install urllib3==1.25.11
```

It also points at a commented out block in steampy/client.py, lines 44 to 48, which is where the fix belongs. That is a very specific piece of advice, and the fact that the project documents it means the situation comes up regularly enough to be worth a FAQ entry.

The second is multiple instances. Multiple accounts are supported, but you need to copy the program several times and run each copy in a different folder. There is no built in profile switching, which makes sense given that each instance holds its own credentials and its own cookies.

The third is turning a feature off. To disable the automatic BUFF delivery, set buff_auto_accept_offer.enable to false in config/config.json5, which is a good sign, because a tool that acts on your behalf should let you switch the risky behaviour off without editing code.

One more note on the configuration format. The config file is JSON5, which supports comments, and some editors report a syntax error on it that does not affect the program at all.

## Conclusion

Adopt Steamauto if you trade game items across several Chinese marketplaces and the repetitive part of accepting offers and relisting is what you want to hand over. Do not adopt it as a black box on an account you cannot afford to lose, because the design requires handing over Steam credentials, cookies and an RSA key, and the seller offer path submits an encrypted Steam cookie to a third party. Verify first that you have read the security notes in the readme, that the files holding your Steam account information, the BUFF cookies, the YouPin token and the RSA key are never committed or screenshotted, and that the marketplaces you use permit the automation you are enabling.

## FAQ

### What does the Steamauto tool do?

It automates selling and delivering game items across NetEase BUFF, YouPin, ECOsteam, C5Game and Steam, handling delivery type quotes automatically, relisting items for rental and sale, adjusting prices, synchronising listings between platforms, and pushing notifications about logins, deliveries and failures.

### How do I run Steamauto from source?

Run pip install -r requirements.txt and then python Steamauto.py. The first run generates config/config.json5 and config/steam_account_info.json5, and you fill them in before running it again and completing the platform logins it prompts for.

### Which files must I keep secret?

The readme says not to publish config/steam_account_info.json5, config/buff_cookies_*, config/uu_token_* or config/rsakey.txt, and not to post screenshots or logs containing accounts, passwords, tokens, cookies or private keys in a public issue.

### How does Steamauto send notifications?

Through the notify_service setting, which uses the Apprise format and supports Telegram, DingTalk, Feishu, WxPusher, Server Jiang and others. You can set a custom title, include or exclude the Steam account information, and list blacklist_words so notifications containing them are not sent.

### Can I run Steamauto for several accounts?

Yes, but you have to copy the program several times and run each copy in a different folder, since each instance holds its own credentials and cookies. There is no built in profile switching.

### What is the Python version requirement and the packaging story?

The project requires Python 3.12 or newer, uses the pdm-backend build system with a pdm.lock, and the release downloads are built with PyInstaller from the build.spec file. The linting is done with ruff and the configuration is in ruff.toml.

## Sources

- [Issues](https://github.com/Steamauto/Steamauto/issues)
- [License: AGPL-3.0](https://github.com/Steamauto/Steamauto/blob/master/LICENSE)
- [README](https://github.com/Steamauto/Steamauto/blob/master/README.md)
- [Releases](https://github.com/Steamauto/Steamauto/releases)
- [Steamauto/Steamauto on GitHub](https://github.com/Steamauto/Steamauto)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/steamauto-steamauto