W Social Scraper — Verified Accounts, Posts & Engagement

W Social is the European social network built on the AT Protocol, where every account carries the network's own answer to the question everyone else guesses at: is this a human? This Actor reads any public account — its verification, its posts with every engagement count, who it follows, its livestreams — and reads individual posts by link.

Public API. No key, no login, no proxy needed.

Paste a post link, get its numbers

Drop https://wsocial.eu/profile/anna.wsocial.eu/post/3mtnzyolvcs2i into Post links and get back likes, replies, reposts, quotes, bookmarks, the engagement rate against the author's real follower count, what the post replies to, and — if you ask for it — the whole reply thread with each reply's own engagement and how deep it sits.

One post from the sample: 115 likes, 17 replies, 13 reposts, 2 quotes, 5 bookmarks, a 4.65% engagement rate, and 23 replies read down four levels.

The field that exists here and nowhere else

Every account carries accountType — human, organization, bot, service or unverified — and this is the network's own classification, not an inference. Across 576 accounts sampled: 385 human, 144 unverified, 35 organization, 8 bot, 2 service.

Two honest notes about it. The verification method (wid for people, admin for everything the staff approved) is not an independent signal — it follows from the type exactly, in all 576 cases. And an account with no type is not an unverified one: W Social federates with the wider AT Protocol network, so a followed account may live on Bluesky, where this field does not exist. Those are flagged isFederated rather than being quietly counted as unverified.

What you get per account

Identity	Handle, DID, display name, bio, avatar, banner, join date, custom domain, labels
Verification	Account type, verification route, human flag, federated flag
Audience	Followers, following, follower ratio
Output	Posts, originals, replies and reposts counted apart; posts in the last 7/30/90 days; dormancy
Engagement	Total and average likes, reposts and replies; engagement per post; engagement rate against followers; the top post
Content	Hashtags ranked by use, languages ranked by use, outbound links
Graph	Who the account follows — resolved into real handles with their follower counts and verification, plus how many of them are humans
Livestreams	The account's stream records, a W Social feature standard AT Protocol clients do not carry

Discovery: read the whole network

The server publishes its own account list, so this Actor can find accounts instead of only reading the ones you name. Measured: 27,981 accounts enumerated in 7.5 seconds, then filtered by minimum followers, minimum posts, account type, verification, or "posted within N days".

Filters run in cost order — followers and post counts are checked on the profile before any feed is read, and "posted within" is answered from the first page, so an account that fails it costs one request instead of a full walk.

Monitor mode

changeType	Means
verification_change	The account's type or verification moved — on a network whose whole proposition is verified humans, this is the event worth waking up for
handle_change	They changed the domain they post under, with the old and new value
new_posts	They published since the last run, with the posts themselves
profile_change	Display name or bio moved
went_quiet	The run where they crossed your dormancy threshold — announced once, not repeated
followers_up / followers_down	Audience moved, with followersDelta
suspended	The network has taken the account down — reported as its own event, not folded into "gone", because who removed it is the whole story
deactivated	The owner switched their own account off
no_longer_available	The account is gone for some other reason — deleted or renamed
new, unchanged	First sighting / nothing moved

Those three are told apart by what the network actually answers — AccountTakedown, AccountDeactivated, or nothing at all — enumerated across 1,000 live accounts rather than guessed at. In that sample 21 accounts were suspended and 5 deactivated.

History is tracked by DID, not by handle. On this network a handle is a domain name and can change; keyed by handle, a rename would read as one account vanishing and another appearing.

An account that 404s but was never in your baseline is a typo, and is reported as one rather than as news.

Notes & limits

Properties of the source, measured rather than assumed:

• The author feed carries replies and reposts as well as original posts, which is why it returns more items than the profile's own post counter — 1,014 items for an account reporting 973. Those 973 are matched exactly once reposts are excluded, and reposts are never averaged into the account's own engagement, because they are somebody else's numbers.
• A repost carries the original post's date, not the date it was reposted. Counting reposts into a "posts this month" window would therefore date them wrongly, so activity windows use original posts only.
• A window the read did not cover is left empty. On a prolific account 100 posts can span three days; reporting that as the monthly total would under-count them and look like a slowdown that never happened. oldestPostRead says exactly how far back the read got, and firstPostAt is filled in only when the walk actually reached the account's first post.
• Every 400 from this network is named InvalidRequest — a missing account and a malformed request are the same error code, and only the message tells them apart. This Actor reads the message, so a bug in a request is reported as a bug rather than as "that account does not exist".
• The server's own account list is not to be trusted about who is inactive. Of 56 repositories it marked inactive, all 16 taken-down ones really were gone — but 13 of the 40 marked "deactivated" served a full profile anyway. Only the taken-down flag is believed here; everything else is asked about directly, because skipping them all silently dropped live accounts.
• handle.invalid is not a handle. It is what the protocol shows when an account's domain stops proving ownership, several unrelated accounts carry it at once, and a link built from it goes nowhere. Those accounts are flagged handleInvalid and linked by DID instead.
• The follow graph is closed on the app API and open on the repository. Followers, search, likes and the timeline all answer AuthMissing; follows, posts and livestreams are readable straight from the account's own repository, which is where this Actor reads them.
• Follow records name only a DID. Handing over did:plc:wn2b3igg… would be handing over something unusable, so each is resolved back into a handle with its follower count and verification — 25 per request, the documented ceiling.
• replies and repliesRead are different numbers on purpose. The first is the platform's count of direct replies; the second is how many were actually read, including nested ones deeper in the thread.
• No rate limiting observed. 80 accounts with full post lists finished in 28 seconds; a full walk of one account's 1,014 posts took 23 seconds.
• The Actor honours your Maximum cost per run and stops when the cap is reached.

Input

Field	What it does
Accounts	Handles, DIDs or profile URLs — ingmar.wsocial.eu, did:plc:…, or a full link. Institutions use their own domain.
Post links / Include the reply thread	Metrics for individual posts, optionally with the replies underneath.
Discover accounts / Accounts to scan	Read the network instead of naming anyone.
Minimum followers / posts, Account types, Only verified, Posted within	Filters. They narrow a named list too, not only discovery.
Read posts / Posts per account	How far back to read. This is what the averages and windows are built from.
Include the individual posts	Adds every post read rather than just the totals.
Include the follow graph / Follows per account	Who they follow, resolved into handles.
Include livestreams	Their stream records.
Treat as dormant after	Your definition of quiet, not a hidden constant.
Monitor mode / Output only changes	The alert behaviour above.