WeChat Article Metrics Scraper — 公众号文章阅读/点赞/分享/收藏数
Pricing
from $0.10 / actor start
📊 WeChat Article Metrics | The read and share counts behind an article Fetch public interaction metrics for any WeChat Official Account article: read count, like count, share count, collect count, comment count and star count. Two engines — a full-metrics default and a lighter h5 mode.
The 5-runs-per-day free cap is gone, because it never worked. The counter is replaced by the platform's pay-per-event charge, which is enforced on every run by Apify instead of by us.
Why: the counter lived in a named key-value store (usage-gate-…) resolved
through the REST API. Every run started through the API executes under
LIMITED_PERMISSIONS, and under that permission set the run token can neither
list nor create a named store. Both calls failed, gate_store.js swallowed
the error and returned null, and the caller silently fell back to the run's
own default store — which is created fresh per run. The counter therefore read
0 every single time.
Measured 2026-11-06:
![WeChat Articles & Official Account Scraper 公众号 [Only $1] avatar](https://images.apifyusercontent.com/jRmFw4tgoSV23DuMCoFH9zz_AylrhlgRlyBKpCB3cBY/rs:fill:76:76/cb:1/aHR0cHM6Ly9hcGlmeS1pbWFnZS11cGxvYWRzLXByb2QuczMudXMtZWFzdC0xLmFtYXpvbmF3cy5jb20vbmduOHZSRVNUa3NleVdFNnAtYWN0b3ItbWQ5S3BWZDBQcEh6Y1E2c2ItUTFJbmFVcEZ4YS13ZWNoYXQucG5n.webp){kind=avatar}
Free tier 1/5.usage-gate-* stores exist; 48 hold a record; every record is dated
2026-10-03..05 and carries our own APIFY_USER_ID — all of them from local
test runs. Not one record belongs to a real user.src/gate_store.js is deleted rather than left disabled — a gate that still
reads a store but never blocks is exactly how a month of silent
non-enforcement looked normal.
Output change: freeTierRunsToday, freeTierCapDegraded and
freeTierCapDegradedReason are removed from both the notice row and the
SUMMARY record. tier (free / paid) is still reported, as information.
A rejected input no longer reports a failed run. A link that is not a
WeChat article — a Douyin or Xiaohongshu URL, or mp.weixin.qq.com without
the /s path — used to throw from validateInput and end the run with exit
code 91. Measured on the live 0.7.1 build on 2026-11-06:
url=https:// example.com/…main.js:45.
Nothing was requested from WeChat and nothing was billed upstream, so this is
a business result, not a broken Actor. The run now finishes successfully and
the dataset carries one type: 'notice' row with reason (what was wrong)
and url. SUMMARY gains ok: false and invalidInput: true.
Running out of Apify spending credit no longer reports a failed run.
This Actor is priced pay-per-event ($0.06 per start event until 2026-11-03,
$0.10 from then on). A paying caller who hits their own limit got the metrics
and then had Actor.charge throw, which turned an already-delivered result
into a FAILED run — one more red mark on the Store page for every retry.
The refusal is now logged and surfaced as a status message; the run stays
successful. Whether the charge is owed is the platform's call, not ours to
enforce by failing.
Context: in the 30 days to 2026-11-06 this Actor ran 1988 times, of which 550 FAILED — 81% of the whole fleet's failures — holding its Store success rate at 72%.
A URL with no metrics 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 throw on the empty result 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: 19 of this Actor's 82 runs in 30 days failed this way, holding its Store success rate at 77%. The upstream is charged for the call whether or not the run succeeds, so ending the run early saved the user nothing.
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
noMetrics: truetype is
notice.
A response with no metric fields no longer produces an all-null row.
The normaliser accepted a payload that carried a data object but none of
the metric fields, so the dataset got a record whose every value was null —
a dataset that looked populated while saying nothing. Such a payload is
now reported as a notice instead.
A transient risk-control window is retried instead of killing the run.
This upstream answers such a window with HTTP 400 and a body that says
"Request failed. Please retry." — and waives the charge. This Actor's
retry rule covered 429 and 5xx only, so every one of those windows was
fatal; the declared three attempts never fired. The sibling Actor
wechat-article-detail-scraper received this fix on 2026-10-11 and this
Actor never did. A 400 is still only retried when the body itself asks
for it, so a genuinely malformed request is not retried three times at
triple the cost.
The default endpoint now falls back to the h5 endpoint. The two are
separate upstream paths, so a risk-control block on the default one does
not imply the h5 one is blocked too — measured on the sibling Actor, the
default endpoint answered 400 while h5 answered 200 for the same URL. This
Actor picked one endpoint and never tried the other. The SUMMARY record
now carries engineFellBackToH5 and the engine that actually answered.
The URL check matches the rest of the family. It now uses the same
pattern as wechat-article-detail-scraper and
wechat-article-comments-scraper, and keeps accepting the optional
subdomain prefix it accepted before. The change is a widening only.
LIMITED_PERMISSIONS — how Apify's automated QA and every API-triggered run
starts an Actor — opening the store is refused with HTTP 403
(KeyValueStoreCollectionClient.getOrCreate, path /v2/key-value-stores).
That call sat in a || fallback chain and was never inside a try/catch of
ours, so the throw ended the run with exit code 91 and a reported FAILED run
with zero items. Every store open now goes through a wrapper that returns a
no-op store instead of throwing, so the free-run counter and the run SUMMARY
degrade and the actual work proceeds./v2/key-value-stores; it used a fixed limit=50, which silently
stopped containing gate stores once the account passed 50 of them — and the
account creates a new default store on every run, so that list grows on its
own. The lookup now pages (100 per page, up to 20 pages).defaultRunInput to .actor/actor.json (Layer 3 of §226).DEFAULT_URL) instead of running with the defaultRunInput the schema advertises.defaultRunInput mirrors schema defaults 1:1 (url, engine, commentId, raw), so empty-input runs now execute the schema-declared defaults.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.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.
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.
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: content was fetched (title and length 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.
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, 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.