WeChat Official Account Article Scraper 公众号 | Body & Comment ID
Pricing
$0.06 / actor start
Extract the full text of any WeChat Official Account article in ~30 seconds: clean plain-text body, title, author, account identity, publish time, cover, and comment ID in one JSON row. No WeChat login, no cookies.
A URL with no article at it no longer reports a failed run. The upstream answers a deleted, non-public or mistyped article with HTTP 200 + code 200 and puts the reason in the body ("请求参数可能有误（如无效的文章 URL…）请 检查参数后重试。注意：使用无效参数的请求被微信处理后仍会计费。") — the request was answered, and the answer is "there is no such article". The Actor used to treat that as a fault and end the run with exit code 91, so the Store counted a normal answer as a broken Actor.
Measured 2026-10-21 on the platform: 31 of this Actor's 66 runs in 30 days failed this way, holding its Store success rate at 53%. The upstream is charged for the call whether or not the run succeeds, so ending the run early saved the user nothing and cost them a red run.
The run now finishes successfully and the dataset carries one
type: 'notice' row explaining what happened, with the upstream's own
reason attached. The SUMMARY record gains ok: false and
noArticle: truetype is
notice.
The URL check no longer rejects links WeChat itself produces. The
pattern used to require the whole string to match, which turned away
…/s/<id>#rd (the anchor the share dialog adds) and …/s/<id>/ (a
trailing slash) — both of which users paste verbatim. They are accepted
now. The check was also a widening rather than a narrowing of what was
accepted before: the optional subdomain prefix (…mp.weixin.qq.com) is
kept, and a bare …/s is passed to the upstream, which answers it
precisely. A local check stricter than the upstream only produces failed
runs the upstream would have answered.
The rule is now identical to the one in wechat-article-metrics-scraper
and wechat-article-comments-scraper. Sibling Actors disagreeing about
what a valid input is is a bug, not a matter of taste.
All notable changes to this Actor are documented here. The format follows Keep a Changelog .
Root cause of the ~20% Store success rate, found by reproducing it against the live platform rather than by reading the code alone.
Transient upstream 400 was never retried, so a single hiccup failed the run. upstream_client.js classified retryability as status === 429 || status >= 500. This upstream answers risk-control windows with HTTP 400 and a body that says Request failed. Please retry. (and waives the charge). 400 was therefore marked non-retryable and the loop broke on the first attempt — the declared attempts = 3 never fired once. Measured on the live Actor: 6 distinct URLs → 2 succeeded / 4 failed, all four on the same 400, clustered over 14:44:24–14:45:04. Re-running those exact same four URLs plus two controls minutes later: 8/8 SUCCEEDED. The 400 is transient; the retry machinery simply never ran.
400 is now retryable, but only when the response body itself asks for it (/please retry|请重试/i), so a genuinely malformed request still fails on the first call instead of burning three.
Backoff was too short for the observed block window. 500 × 2^(n-1) meant 500 ms / 1 s against a window measured at ~40–90 s. Now 1 s / 3 s / 7 s. Worst case stays bounded at ~191 s (3 × 60 s timeout + 11 s backoff), inside Apify's 5-minute automatic-test limit.
raw=true was pure overhead. The default engine sent raw: true to the upstream, inflating the response from ~38 KB to ~52 KB — ~33 KB of which is content_noencode, the raw HTML that nothing in this Actor reads. rawData on the output is the normalised data object, which returns either way, so no field is lost. Every other WeChat Actor in the fleet already sends raw=false; this was the sole outlier.
Automatic h5 fallback. fetch_article_detail and fetch_article_detail_h5 are separate upstream paths, so a block on one does not imply the other is blocked — verified live: default returned 400 while h5 returned 200 for the same URL. When the default engine exhausts its retries with a transient error, the Actor retries once on h5. The cost is alias and the two head images; the body survives, which is the point of this Actor. Business errors (upstream code !== 200) are marked retryable = false and deliberately skip the fallback — they would fail identically at double the cost.
SUMMARY now carries engine (the endpoint that actually answered, not the one requested) and engineFellBackToH5, so a fallback run is distinguishable after the fact.
Tests: 3 unit scenarios (transient 400 retried → 2 calls; permanent 400 → exactly 1 call; exhausted retries still throw) and 3 integration scenarios (400 survives into a real row; default → h5 fallback produces a row flagged as such; explicit h5 failure has nowhere to fall back to and fails honestly). 11 → 14 integration scenarios.
Before the fix — 6 distinct URLs, run serially: 2 succeeded / 4 failed, all four failures on the same HTTP 400 Request failed. Please retry., clustered between 14:44:24 and 14:45:04 (a ~40 s risk-control window). Re-running those exact same four URLs plus two controls a few minutes later: 8/8 SUCCEEDED. The 400 is transient; the retry loop simply never ran.
After the fix (build 0.9.1, tag latest):
| Set | Result |
|---|---|
| The same URLs that failed 4/6 before | 5/5 SUCCEEDED |
| 14 further distinct articles (stress set) | 14/14 SUCCEEDED |
19 consecutive successes across both sets, no HTTP 400 failures. Spot-checked row: alias and headImage present (default engine answered, no fallback needed), contentTextLength populated, no rawData on the row, SUMMARY.engine = "default", SUMMARY.engineFellBackToH5 = false.
The upstream was clear during both post-fix windows, so no run happened to need a retry — retries was 0 throughout. The retry and fallback paths are covered by tests instead: integration scenario 12 (400 → retried → row produced) and scenario 13 (3 default attempts exhausted → h5 fallback → row produced and flagged).
package.json was stale at 0.5.0 while actor.json was at 0.8. Both now read 0.9.retryable expression still sits unfixed in ~50 sibling Actors (douyin, twitter, the rest of wechat, xiaohongshu, the radar family), of which ~12 have no retryability classification at all. 19 siblings already use the retryOn opt-in. This Actor was only the first one reported. The sweep is the next job.Actor.setValue does not just fail
under LIMITED_PERMISSIONS — it can simply never resolve. Measured on a live
run of a sibling Actor: results were fetched successfully, then the following
setValue never returned and the run sat for 49 minutes before being aborted
with an empty dataset and a $0.08 bill, and not one error in the log.
try/catch cannot help with that — it catches a rejection, not a promise that
never settles. SUMMARY and the other bookkeeping writes now race a15s timeout
and report the failure, so a stuck store costs one summary field instead of
the whole run.A successful fetch could end with an empty dataset and no error. pushData
and setValue('SUMMARY', ...) fail silently under LIMITED_PERMISSIONS —
the SDK swallows the permission error, the run still reports SUCCEEDED, and
the caller cannot tell "found nothing" from "found something I could not
store". Confirmed on a live run: the article was fetched (real title and
2998 chars in the log) while the dataset held 0 items and SUMMARY was absent
entirely. Both writes are now wrapped, and a blocked dataset write sets an
explicit status message instead of passing for success.
The daily free-run counter could take the whole run down. The gate had no
try/catch at all: checkAndIncrementFreeRuns called openGateStore(),
getValue() and setValue() in the open, so any failure propagated straight
out and killed the run. Apify's automated QA executes under
LIMITED_PERMISSIONS, where the named-store REST create is rejected — so this
fired on QA runs and, for this Actor, dragged the store-page success rate
down to 23.8%, the lowest in the fleet.
The whole open→get→set sequence now sits in one try. On failure the gate
reports through log.error + log.warning and returns
{allowed:true, degraded:true, degradedReason}, so the run continues
uncapped for that run. A genuinely exceeded cap still returns allowed:false
and remains a hard stop — that is the one case where failing closed is right.
freeTierCapDegraded / freeTierCapDegradedReason.
Without it a run that sailed past the cap is indistinguishable from one that
was properly counted, after the fact.checkAndIncrementFreeRuns and FREE_DAILY_RUN_LIMIT are now exported, so
the cap can be asserted on directly rather than inferred.test/gate-degradation.js to npm test. It asserts both directions:
a broken store must fail open, and a healthy store must still return
allowed:false once the cap is reached — a gate that fails open
unconditionally would also pass a degrade-only test while never counting
anything again.test/gate-degradation.js, wired into npm test. It asserts both
directions: a broken store must fail open, and a healthy store must still
return allowed:false once the cap is reached — a gate that fails open
unconditionally would also pass a degrade-only test while never counting
anything again.$0.06 per Actor run (the Apify-configured apify-actor-start event). The article-detail-result per-article event will NOT be added to Console Monetization.safeCharge('article-detail-result', …) call and helper from src/main.js — the event was never configured in Console, so every paid run logged a swallowed "Charge failed" warning. The $0.06 start charge is collected automatically by the platform; no in-code Actor.charge() remains.(#) links replaced with full apify.com/opspilot.cc/... URLs; this Actor removed from the table (a "This Actor is step ②" line points to it instead); ghost reference wechat-article-search-scraper corrected to the real wechat-universal-search-scraper; added WeChat Account Articles Scraper.$0.06 per Actor run (Actor Start) — the previously claimed $0.01 per article (article-detail-result) event is NOT configured in Console and never charged.actor.json title now carries the Chinese keyword 公众号 (WeChat Official Account Article Scraper 公众号 | Body & Comment ID); description and seoTitle/seoDescription rewritten EN-first with hook + keywords (Store card previously used "EN — / ZH —" mixed copy).URL_PATTERN only matched short links (/s/<id>); long links (/s?__biz=...&mid=...&idx=...&sn=... — the shape WeChat share dialogs emit and what WeChat Universal Search Scraper outputs) failed validateInput before any upstream call. README and schema already claimed long links work; now they actually do. Verified: short + long link regex cases pass, and 3 search-issued long links fetched end-to-end (16581 / 1381 / 1613 chars).code: 200 with an error message inside data for dead URLs (and still charges for the call). The normalizer now detects the shell payload (data.content missing / upstream invalid-URL message) and the run fails with a clear error ("Article not found, deleted, or URL is invalid… Upstream said: …") instead of pushing empty data and billing the user.package.json version re-aligned to 0.3.0 (was stale at 0.1.0 while actor.json was at 0.2).__biz query, bare /s rejection), shell-payload normalization → null.ll7slAByvADDVf2tf SUCCEEDED — search-issued long link /s?__biz=...&mid=...&sn=...&chksm=... fetched 16581 chars (品牌出海海贸会).4eJynk33lA62BXPSq FAILED with Article not found, deleted, or URL is invalid… Upstream said: 请求参数可能有误… — no dataset row, no charge event.eCsGLXWQneHz8ed6l (build 0.3.2) SUCCEEDED.EnVwYCmZza4FKTcWa (datacenter-IP risk control, not reproducible locally at the same moment; clean run succeeded next attempt). Untouched by this release, but motivated the error-message fix below.[object Object]: the response body is now JSON-serialized (up to 400 chars) so 4xx diagnostics show the real upstream reason.0.1.1 (id CXeuzFSgADb9GQk5O) — Actor id 5vrr8dBcnclIva0Lx.g6g3UykReGEkr6cIA, status SUCCEEDED, 8.57 s, exitCode 0. Dataset item returned all expected fields (title / nickName / ghUsername / alias / publishTime / commentId / contentTextLength / contentTextTruncated / headImage).fetch_article_detail endpoint (default engine) returns full plain-text body, title, author, account identity, head image (round + HD), cover, album info, and comment_id.fetch_article_detail_h5 endpoint variant exposed via engine=h5 (faster but alias / head images are null).comment_id always string-typed (JS-safe). msgId may be string or number depending on the upstream's actual payload length.maxContentChars truncation (0 = no truncation, capped at 200000).rawData attachment when raw=true.APIFY_USER_IS_PAYING !== '1').article-detail-result.code=200, contentText length=2998, comment_id=3884868893382230017, alias=QbitAI).raw=false to keep the payload small).defaultRunInput to .actor/actor.json (§226 Layer 3). The Actor now runs out-of-the-box without any user input — Apify Store QA bot no longer hits "url is required" and the Actor is removed from "Under maintenance" status.0.2.2 (id Wq72hNh167j2ZY6aC, tagged as latest). Actor id 5vrr8dBcnclIva0Lx.apify call 5vrr8dBcnclIva0Lx --input '{}' → run eb4riT0s3qA3NTdag, status SUCCEEDED, ~7 s. SUMMARY autoFilled: [] (vs autoFilled: [url, engine, raw, maxContentChars] on 0.1.7) confirms the Apify runner pre-populates the input from defaultRunInput before main.js runs.apify push does not move the latest build tag by itself when bumping the Actor version. After bumping version you must re-run with -b latest (or set buildTag in actor.json) to point latest at the new build. The first push of 0.2 created build 0.2.1 but kept latest on 0.1.7; the second push with -b latest -f overwrote the build as 0.2.2 and re-tagged latest.main.js. The schema defaults (Layer 1) and applyDefaults() fallback constants (Layer 2) from 0.1.0 still apply — defaultRunInput is a third, more reliable layer for the Apify Store QA bot specifically.