WeChat Official Account Scraper

A Lantern Lab Actor. Collect public data from WeChat Official Accounts (微信公众号): articles with their engagement counts, comments with reply threads, article and account search, and an account's post history. No WeChat login, no cookies, no account of your own.

Every row says how complete it is. When something could not be read, the row is marked partial or failed with the reason - a failed article is never reported as "0 comments".

What it does

Pick one mode per run:

Mode	Input	One row per
articles	article links	article: title, author, account, publish time, text, plus reads, likes (赞), Wow (在看), shares, favorites and comment count - in one row, one charge
comments	article links	comment and reply, plus one summary per article
articleSearch	keywords	matching article, plus one summary per keyword
accountSearch	keywords	matching Official Account (with verified owner and original-article count), plus one summary per keyword
accountArticles	account IDs (gh_...) or exact names	article in the account's post history, plus one summary per account

What it does not do

• Only what WeChat shows publicly. WeChat shows the comments the author has featured (精选). When WeChat counts more comments and replies than it shows, the article's summary row is partial and says how many are hidden.
• No WeChat Index, search suggestions or mini-program search.
• No commenter IDs or avatars: only the public nickname and the region WeChat shows next to a comment.
• No scheduling or monitoring built in; use Apify schedules.

Input

Field	Default	Used by	Meaning
mode	articles	all	What to collect (see above).
articleUrls	-	articles, comments	Links like https://mp.weixin.qq.com/s/... or https://mp.weixin.qq.com/s?__biz=...&mid=...&idx=...&sn=....
includeText	true	articles	Add the article body as plain text.
includeHtml	false	articles	Add the article body as HTML.
maxCommentsPerArticle	100	comments	Top-level comments per article.
includeReplies	true	comments	Collect replies under each comment.
maxRepliesPerComment	20	comments	Replies per comment thread.
keywords	-	search modes	One search per keyword.
maxResultsPerKeyword	20	search modes	Results per keyword.
maxPagesPerKeyword	-	search modes	Hard ceiling on the search pages read per keyword. Each page is one request and one page event. 1 means exactly one request per keyword and every result that page returns. Empty means no ceiling.
searchSort	relevance	search modes	relevance, latest or popular.
searchTimeRange	any	articleSearch	any, day, week or halfYear.
accounts	-	accountArticles	gh_... IDs, or names that match an account name or WeChat ID exactly.
maxArticlesPerAccount	20	accountArticles	Articles per account, newest first.
publishedAfter, publishedBefore	-	accountArticles	Date range (UTC, inclusive).
maxUpstreamRequests	derived from your input	all	Hard ceiling on the requests this run may send to the data source, across every mode and input line. Counted in HTTP attempts, so an internal retry uses one up. 0 means no request is sent at all. Leave it empty and the Actor works the ceiling out from the mode and the limits you set, which is enough to finish the run you asked for; your own value always wins. See Limits.

Example - two articles with engagement counts:

{
  "mode": "articles",
  "articleUrls": [
    "https://mp.weixin.qq.com/s?__biz=MzA5NDM0NDcxNg==&mid=2655753720&idx=1&sn=4c04102cef0abd595053213adbf8b0b5",
    "https://mp.weixin.qq.com/s/gB6VF0eC2tJcBX6RM4AYqA"
  ]
}

Example - comments and replies:

{ "mode": "comments", "articleUrls": ["https://mp.weixin.qq.com/s/gB6VF0eC2tJcBX6RM4AYqA"], "maxCommentsPerArticle": 200 }

Output

One dataset; recordType tells the rows apart. Four table views are predefined (Articles, Comments and replies, Search results, Account post history). A RUN_SUMMARY record in the key-value store has run totals.

Fields on every row:

Field	Meaning
recordType	article, comment, reply, article_search_result, account_search_result, account_article, or a *_summary row for each input line.
collectedAt	When we collected the row (UTC).
publishedAt	When WeChat says the article, comment or reply was published (UTC).
collectionStatus	complete, limit_reached (stopped at your limit), partial (something WeChat shows could not be read), empty (WeChat shows nothing, e.g. 0 comments) or failed (nothing could be read - not the same as empty).
statusReason	Why the row is not complete, or what WeChat does not show.

Article rows (articles mode): articleId (<__biz>_<mid>_<idx>), articleUrl, shortUrl, title, author, digest, accountId (gh_...), accountName, accountAlias, accountBiz, publishedAt, contentType, isOriginal, sourceUrl, coverUrl, ipRegion, albumTitle, text, html, readCount, likeCount (赞), wowCount (在看), shareCount, favoriteCount, commentCount (comments and replies), commentsEnabled.

Comment and reply rows: articleId, articleUrl, commentId, parentId (for replies: the comment's commentId), text, authorNickname, ipRegion, isAccountReply, isPinned, likeCount, replyCount, repliesCollected, publishedAt. Reply IDs are <commentId>-<reply number>.

comments_summary: reportedCommentCount (comments and replies WeChat counts - the same number as commentCount in articles mode), commentsCollected, threadsWithReplies, expectedReplies, repliesCollected, threadsIncomplete, threadsLimited.

Search rows: keyword, rank, and the article (articleId, articleUrl, title, digest, accountName, publishedAt) or account (accountId, accountName, accountAlias, accountType, description, verified, verifiedEntity, originalArticleCount, avatarUrl). Search summaries: reportedTotal, resultsCollected, pagesRead.

Account history rows: accountId, accountName (when the input was a name), articleId, articleUrl, title, digest, positionInPost, contentType, isPaid, coverUrl, publishedAt, updatedAt. account_summary: articlesCollected, oldestPublishedAt, newestPublishedAt.

Large IDs are strings. Counts are what WeChat reported at collectedAt and change over time.

Backup data source (RUN_SUMMARY)

This Actor reads one data source and has no backup channel, so RUN_SUMMARY always reports backupConfigured: false and backupUnavailableKind: "not_configured". Both are a statement about how the Actor is built, never about this run: read backupConfigured first and stop there. What the Actor's own source did is in upstreamAttempts, upstreamBilled, upstreamCapped and stoppedReason, and what each input line returned is in its summary row. The fields are named the same as in our other Actors so one rule can read every run summary. The human-readable backupUnavailable sentence belongs to Actors that do have a backup channel and is not written here.

Pricing

Pay per event:

Event	Charged for
article	One article with its text and engagement counts (articles mode). Not charged when the link fails.
page	Each page WeChat returns in the other modes: up to 20 comments, a page of replies, a page of search results, a page of post history, or an account name lookup. A link WeChat rejects in comments mode still costs one page.
comment	Each comment or reply row.
article-search-result	Each article search result.
account-search-result	Each Official Account search result.
account-article	Each article from an account's post history.

Summary rows are free. Replies that WeChat already shows under a comment cost no extra page. Set a maximum charge for the run and the Actor stops before going over it; the run summary says it stopped early.

Limits

• maxUpstreamRequests is a hard ceiling, not a target: the run sends at most that many requests to the data source, counted in HTTP attempts, so an internal retry of a request that timed out uses one up. Reaching it gives you incomplete results: collection stops where it is, every row already written is kept, and the affected summary row is partial (when it had results) or failed (when it had none), with stopReason upstream_request_cap and a statusReason that says which ceiling stopped it, not WeChat. Nothing is billed for a request the ceiling stopped, because it is never sent.
• Every run has this ceiling, including one that does not ask for it. When you leave maxUpstreamRequests empty, the Actor works it out from the mode and the input you gave it: input lines x requests per line x 2 + 2. The requests one line needs are 2 for articles (engagement, then the body), ceil(maxCommentsPerArticle / 10) for comments, ceil(maxResultsPerKeyword / 10) for articleSearch and accountSearch (lowered to maxPagesPerKeyword when you set it) and 1 + ceil(maxArticlesPerAccount / 5) for accountArticles. The doubling covers a retried request, the two spare cover the overlap between pages, and only the list the mode actually reads counts - so the default is enough to finish the run you asked for, and a single run cannot send an unbounded number of requests. One keyword and the default 20 results give 6. A value you pass yourself always wins, whether it is larger or smaller. The run summary reports which of the two was used in upstreamCapSource (input or derived) and the number itself in upstreamCap.
• maxUpstreamRequests: 0 sends no request at all. Every input line is then reported as failed with upstream_request_cap, which is not the same as an empty result.
• The ceiling applies to the whole run, so with several keywords or links the last ones can be the incomplete ones. The run summary reports upstreamAttempts (HTTP attempts, the number the ceiling counts), upstreamBilled (attempts the data source answered), upstreamCap, upstreamCapSource and upstreamCapped.
• maxPagesPerKeyword limits the search pages per keyword. The page being read is always finished first, so maxPagesPerKeyword: 1 with maxResultsPerKeyword: 20 is exactly one request per keyword and every result that page returns. When WeChat still has more, the keyword is partial with stopReason max_pages_per_keyword - told apart from stopping at maxResultsPerKeyword, which is limit_reached - and pagesRead shows how many pages were read. When WeChat had no more results, the page limit cut nothing and the keyword stays complete.
• maxPagesPerKeyword is optional and has no default of its own: left empty, paging stops at maxResultsPerKeyword, when WeChat runs out of results, or at the request ceiling above, whichever comes first.

Tips

• An article with 0 comments costs one page and returns an empty summary.
• A date range on accountArticles pages through newer posts first; old ranges on very active accounts read more pages.
• Search paging stops when two pages in a row add no new result, even when WeChat says it has more; the keyword summary is then partial and says how many pages were read.
• Use articles mode first to see commentCount, then run comments only for the articles you need.
• Links copied from WeChat carry tracking parameters; the Actor strips them and outputs a permanent articleUrl.

Changes

• Build 0.1.7 (2026-10-09): fixed article likeCount and wowCount, which were swapped in earlier builds. likeCount is now likes (赞) and wowCount is Wow (在看). In article rows collected before build 0.1.7, swap the two values. Comment and reply likeCount was not affected.

Feedback

Open an issue on this Actor with a sample link and the output you expected.