wechat-download-api: RSS and multi-format export for WeChat Official Account articles

What wechat-download-api does that a WeChat account alone cannot

WeChat Official Account articles live inside WeChat's own clients and inside the public account's web pages. There is no general-purpose feed, and there is no supported export. The README positions the project against exactly that gap: copying articles one at a time, losing images, and being unable to move an archive to another reader or device.

The service is for people who already administer a WeChat Official Account. That is the entry requirement, and the README states it plainly: you need an Official Account (subscription or service type), and you scan a QR code with the administrator's WeChat to log in. Once logged in, the README says you can fetch public articles from any Official Account, not only your own. That last point is what makes the project interesting beyond a single publisher's own archive.

The output side is broader than a feed reader. Subscriptions generate standard RSS 2.0 with full article content and images, which FreshRSS and Feedly can consume. Separately, a whole account can be packaged into Markdown, HTML, Excel, JSON, Word, PDF or EPUB. The README is explicit that export reads the local database only and does not trigger any WeChat fetching, so a bulk export carries no anti-control risk. It only exports articles whose bodies have already been captured.

How the service works: login credentials, a local database, and two access paths

The architecture visible in the repository is a single FastAPI application. app.py is the entry point, routes/ holds the HTTP layer, utils/ holds shared code, mcp_server/ holds the Model Context Protocol integration, and static/ holds the pages you actually visit. The Dockerfile runs `uvicorn app:app --host 0.0.0.0 --port 5000`, so port 5000 is the whole surface: the admin panel at the root, the login page at /login.html, Swagger at /api/docs, and a health endpoint at /api/health.

The credential model is the part that shapes everything else. You scan a QR code through the WeChat Official Platform backend, and the README says the credentials are saved automatically into .env with a validity of about four days. After that you scan again. That is not a configuration detail; it is the operating rhythm of the deployment. The README also notes a Webhook notification feature that warns 24 hours and 6 hours before expiry and again once expired, with enterprise WeChat robot support, which tells you the authors expect expiry to be a recurring event rather than an edge case.

There are two distinct access paths, and the README separates them carefully. The HTTP interfaces need no authentication from the caller: the WeChat login state is held server-side and used automatically. The MCP endpoint is different. It uses a static Bearer token, and the README says ENABLE_MCP and MCP_TOKEN must both be set or MCP stays disabled. The server mounts at /mcp over streamable-http and exposes six tools: search_accounts, subscribe_account, unsubscribe_account, list_subscriptions, get_recent_articles and read_article. Requests without the correct token return 401.

Anti-control is handled with a combination the README lists as Chrome TLS fingerprint simulation, SOCKS5 proxy pool rotation, and three layers of automatic rate limiting. The dependency list corroborates the fingerprint part: curl_cffi is pinned at >=0.7.0, and that library exists to impersonate browser TLS behaviour.

Installing wechat-download-api with Docker and getting a first export

The README calls Docker the fastest route because it avoids setting up Python. The compose file expects a .env next to it, mounted read-only into the container, while the SQLite database and credentials persist in ./data. Copy the example file, set SITE_URL to the address you will actually reach the service on, and start it.

git clone https://github.com/tmwgsicp/wechat-download-api.git
cd wechat-download-api
cp env.example .env
# edit .env and set SITE_URL to your real address
docker-compose up -d

If you prefer not to clone, the README gives a direct run with the published image, mapping port 5000 and mounting both data and .env. The image is published for linux/amd64 and linux/arm64, so Apple Silicon, Raspberry Pi and ARM servers are covered.

docker run -d \
  -p 5000:5000 \
  -v $(pwd)/data:/app/data \
  -v $(pwd)/.env:/app/.env \
  --name wechat-api \
  tmwgsicp/wechat-download-api:latest

After the container is up, open http://localhost:5000/login.html and scan with the administrator's WeChat. The README notes you do not need a public server for this: localhost is enough for login and for every feature, and a public server or tunnel only becomes necessary when another device, such as a phone RSS reader, has to reach the service.

With login done, the first real use is a subscription. The RSS management page at /rss.html lets you search an account, subscribe, and copy the feed URL into a reader. The README also mentions bulk adding, where you paste several account names at once. Each subscription has a download button next to it for choosing an export format and a time range.

The same export is available over HTTP without any token. The README gives the route as `GET /api/export/account/{fakeid}.{format}`, where the format is one of the seven. Time filtering supports all articles, the last N days, an explicit window, or an incremental range. There is no documented CLI; everything runs through the HTTP API or the web pages.

If you would rather not use Docker, start.sh on Linux or macOS and start.bat on Windows handle environment checks, virtual environment creation, dependency installation and service start. Run start.sh with sudo on Linux and the README says it registers a systemd service with boot autostart, managed afterwards through status.sh, stop.sh and systemctl.

Export format limits and the credential expiry you have to design around

The export table carries hard per-request ceilings, and they are not uniform. Markdown, HTML, Excel and JSON each cap at 3000 articles in one request. Word and EPUB cap at 500. PDF caps at 200. The reason is visible in the table itself: the text and table formats reference images by URL and are described as instant with zero image-fetch bandwidth, while Word, PDF and EPUB embed the images into the file so it works offline. Embedding means fetching every WeChat image, and that is what the lower ceilings protect. For a large account, a full PDF archive is not one operation; it is a sequence of windows.

There is a subtler limit on the same row. Export only covers articles whose bodies have already been captured. Subscribing to an account does not retroactively fill its history, so a fresh subscription followed by an immediate full-account export will produce far less than the account actually published. The README does not document a backfill procedure for historical articles, and it does not document rollback of an export or a subscription.

The four-day credential is the real failure mode. Nothing in the README suggests an unattended path around the QR scan, so a deployment that nobody visits will stop collecting roughly every four days. The webhook warnings reduce the surprise, but they do not remove the human step. If your requirement is a feed that never misses an article without intervention, this design does not meet it. The README also does not document what happens to in-flight subscriptions when the credential lapses, so treat the gap as unknown rather than as handled.

One more boundary worth stating: this is not a WeChat client. It does not read your chats, and it has nothing to do with downloading the WeChat app or its APK. It works on public Official Account articles through the Official Platform backend.

Where wechat-download-api sits next to RSSHub and WeRSS

The closest comparison is RSSHub, the general-purpose feed generator. RSSHub's approach is a large collection of routes, each one reverse-engineering a site's public endpoints, and you run it as one service that serves many sources. wechat-download-api inverts that: it does one source, and it does it by holding a real authenticated WeChat Official Platform session rather than by parsing public pages. The practical difference is the cost of admission. RSSHub needs no WeChat account from you; this project needs an Official Account and a human who can scan for it every few days. In exchange, you get article bodies and images in the feed rather than a summary or a link, plus the seven-format export, which RSSHub does not attempt.

WeRSS is the other name that comes up for the same job, a WeChat-focused RSS generator. The README does not compare itself to either project, so the honest statement is that the difference here is the combination: RSS plus bulk export plus an MCP server in one FastAPI process. If you only want feeds and already run RSSHub, adding a second service that needs a QR scan on a four-day cycle is a real operational cost for a feature you may not use. If you want a local, format-flexible archive of specific accounts, the export path is the reason to pick this one.

Licence, upgrade cost, and what the repository tells you about maintenance

The project is AGPL-3.0. The README's framing is that the code is fully public and self-hosting carries no restrictions, and it explicitly distances itself from projects that use an open source label to sell a hosted tier. That said, AGPL-3.0 is a copyleft licence with a network clause, and the README does not discuss what that means for anyone who exposes a modified version to other users. If you plan to run this for anyone other than yourself, read the licence text in the repository rather than relying on the README's summary. This is a description of the licence, not legal advice.

The repository is not archived, and the last push was on 2026-07-27. Releases are frequent and recent: v1.5.1 on 2026-06-23, v1.6.0 on 2026-07-05, and v1.7.0 on 2026-07-20. The requirements.txt carries a dated comment from 2026-07-05 explaining that MCP support needs newer fastapi, pydantic and starlette versions, with fastapi pinned at 0.137.1, pydantic at 2.13.4 and mcp at 1.27.2. That pinning is a maintenance cost you inherit: upgrading one of those three means checking the others.

Upgrades themselves are cheap on the Docker path. The compose file uses the latest tag, so pulling and recreating the container is the whole procedure, and the database lives in ./data outside the image. The .env mount is read-only in compose while credentials are written to the data directory, which is the detail to preserve if you write your own compose file. NAS users get a note about permission problems and `chmod -R 777 ./data` as the workaround.

Dependency weight is moderate and split by feature. Markdown, HTML, Excel and JSON export need nothing beyond the base install. PDF, Word and EPUB pull in Pillow, xhtml2pdf, python-docx, openpyxl and EbookLib. The mcp package is only needed when ENABLE_MCP=1. A deployment that never exports to PDF or Word and never enables MCP can reasonably trim, though the README does not document a reduced install.

Editorial conclusion

Adopt it if you already administer a WeChat Official Account, can run Docker or Python 3.8+, and want public account articles in your own RSS reader or a local archive. Skip it if you have no Official Account to scan in with, or if you need unattended operation that survives a four-day credential cycle without a human. Before committing, verify three things on your own deployment: that scanning works from your network, that the export formats you care about produce usable files at your article counts, and how you will handle AGPL-3.0 if you expose the service to other people.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. tmwgsicp/wechat-download-api on GitHub