Bluesky Scraper — Posts, Profiles & Followers | $1.50/1K | No Auth Required

Built for researchers tracking Bluesky growth, brand monitors following handles as Twitter refugees, and AI pipelines that need social graph data.

First comprehensive Bluesky scraper on Apify with official AT Protocol API support.

Pricing: $1.50 per 1,000 records (posts, profiles, and graph records combined).

Scrape Bluesky profiles, posts, followers and following lists via the fully open AT Protocol public API (public.api.bsky.app). No API key, no authentication, no browser required.

Pricing example

$1.50 per 1,000 records (posts, profiles, followers combined). 100 posts = $0.15. 1,000 posts = $1.50. 10,000 posts = $15. No per-run fee. No proxy cost.

Sample output

{
  "record_type": "post",
  "handle": "bsky.app",
  "display_name": "Bluesky",
  "did": "did:plc:z72i7hdynmk6r22z27h6tvur",
  "uri": "at://did:plc:z72i7hdynmk6r22z27h6tvur/app.bsky.feed.post/3kd9xyz123",
  "text": "We just crossed 10 million users. Thank you!",
  "like_count": 4821,
  "repost_count": 1203,
  "reply_count": 341,
  "quote_count": 89,
  "has_media": false,
  "is_reply": false,
  "created_at": "2026-05-15T18:22:31Z",
  "parse_confidence": 1.0,
  "warnings": [],
  "scraped_at": "2026-06-05T09:00:00Z"
}

Features

• Profile scraping — handle, DID, display name, bio, followers/following/posts count
• Author feed (posts) — full post text, likes, reposts, replies, quotes, timestamps, language detection, is-reply flag, has-media flag, cursor pagination
• Followers list — paginated list of accounts following a handle
• Following list — paginated list of accounts a handle follows
• Multi-handle batch: pass a list and process all in one run
• parse_confidence + warnings in every record — drift detection built in
• Pay Per Result (PPE) — you only pay for actual records returned

Input

Field	Type	Required	Description
handles	list	Yes	Bluesky handles to scrape (e.g. bsky.app)
mode	string	No	profile_posts (default), followers, following
maxPostsPerHandle	int	No	Max posts per handle. Default 100, 0=unlimited
maxFollowsPerHandle	int	No	Max followers/following per handle. Default 100
includeProfile	bool	No	Also output a profile record in profile_posts mode. Default true

Output schema

Each record has record_type = post, profile, follower, or following.

Field	Type	Notes
record_type	str	Discriminator
handle	str	Bluesky handle
did	str	Decentralized ID
display_name	str|null	Display name
uri	str|null	at:// URI (posts only)
text	str|null	Post body (posts only)
like_count	int|null	Likes
repost_count	int|null	Reposts
reply_count	int|null	Replies
quote_count	int|null	Quotes
has_media	bool|null	Post has embedded media
is_reply	bool|null	Post is a reply
created_at	ISO str	Post creation time
followers_count	int|null	Profile followers (profile records)
follows_count	int|null	Profile following (profile records)
posts_count	int|null	Profile post count (profile records)
description	str|null	Bio (profile records)
scraped_at	ISO str	Run timestamp
parse_confidence	float	0.0–1.0 parse quality score
warnings	list	Machine-readable quality flags

Why this Bluesky scraper beats the alternatives

	This scraper	generic browser-based actors
Price	$1.50/1K	$2-4/1K typical
Official AT Protocol API (no browser)	✓	✗
Followers + following graph	✓	✗
parse_confidence on every record	✓	✗
No auth required	✓	partial
Multi-handle batch	✓	✗

The AT Protocol is fully public — Bluesky exposes complete profile and post data without any API key. Other scraper actors use headless browsers or unofficial endpoints that break on updates. This actor hits the official XRPC API directly: structured JSON, cursor pagination, zero access friction.

Frequently asked questions

Do I need a Bluesky account or API key? No. The AT Protocol public API (public.api.bsky.app) requires no authentication. Any public profile and its posts are accessible without credentials.

Do I need a proxy? No. The AT Protocol is a genuinely open public API — no access restrictions, no datacenter blocking. Zero proxy cost to you.

What formats does output come in? JSON (default), CSV, and Excel — all via the Apify dataset download or REST API. Native integration with n8n, Make, Zapier.

What if a handle returns empty or 0 posts? The actor logs a warning (handle not found) and continues to the next handle. It never crashes on a missing handle — you get results for the handles that did work.

Can I schedule this for daily monitoring? Yes — set maxPostsPerHandle to a low value (e.g. 20) and run on an Apify schedule. Only new posts since the last run appear in the fresh dataset.

Technical notes

• Base: https://public.api.bsky.app/xrpc/
• Pagination: cursor-based, up to 100 items/page
• Rate limits: handled with exponential backoff
• Stack: Python 3.13 + Apify SDK

Monitoring use case

Run on a schedule to track follower growth or new posts for a list of handles. Set mode=profile_posts and a low maxPostsPerHandle for lightweight daily checks. A parse_confidence drop below 0.8 means a required field was missing — easy to detect schema drift in downstream pipelines.

Use with AI Agents (MCP)

This Bluesky scraper is callable as a tool by AI agents (Claude Desktop, Cursor, VS Code, n8n, LangGraph, CrewAI, or any MCP-compatible client) via Apify's hosted Model Context Protocol server.

{
  "mcpServers": {
    "apify": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "https://mcp.apify.com/?tools=bovi/bluesky-scraper",
        "--header",
        "Authorization: Bearer <YOUR_APIFY_TOKEN>"
      ]
    }
  }
}

Keep maxPostsPerHandle low (e.g. 25) when calling from agents to limit token volume.

Integrations

Built for social researchers and brand monitors tracking Bluesky profiles, post engagement, and follower graphs — the JSON/dataset output drops into the tools you already run, no glue code:

• n8n / Make / Zapier — trigger a run or pipe every new dataset item into 500+ apps (Google Sheets, Airtable, Slack, HubSpot, your database) with no code: n8n, Make, Zapier.
• Webhooks — fire your own endpoint the moment a run finishes, to push results straight into your pipeline (docs).
• MCP server — expose this actor as a tool to Claude, Cursor, or any MCP client so an AI agent can pull this data mid-conversation (guide).
• API & SDKs — fetch the dataset as JSON, CSV, or Excel through the Apify REST API or the Python / JS SDKs.

See all Apify integrations.

Usage statistics

This Actor creates a small, content-free summary at the end of each run. It is used only to monitor reliability and improve this Actor. A copy is saved as USAGE_STATS in your own Apify key-value store, so you can see the exact record created for your run.

Set disableUsageStats to true in the input to opt out. Nothing is sent then; your USAGE_STATS record only says that statistics were disabled.

Only these fields are recorded:

• schema version, Actor name and build number;
• UTC start and finish hour (not a precise timestamp);
• run duration, number of results and time to the first result, each as a coarse range;
• whether the result was empty, the end status, and an error type from a fixed list;
• memory setting and counts of charged events;
• names of the input fields you set, never their values;
• the selected option for input fields that offer a fixed list of choices (for example a sort order).

We do not collect input text, search terms, URLs, domains, usernames, email addresses, names, proxy credentials, tokens, scraped records, output items, raw error messages, stack traces, or hashes of any of those values. Records are kept for no longer than 13 months, used only as aggregated operational statistics, and never sold or shared.

Run-outcome signals (v2)

To learn whether a run did what it was asked to do, the record also holds a few more coarse ranges and yes/no flags. None of them contains content:

• the result limit you asked for (a range, when the input has one) and what share of it was delivered;
• results delivered per input item you listed (a range);
• output quality as ranges: how fully the result fields were filled, the share of rows that look like errors, the share of duplicate rows, and how many different fields appeared. These are counted in memory while results are saved; no result content is kept;
• how the run was started (console, API, schedule, webhook, another Actor);
• how it ended: stopped by you, timed out, reached the requested limit, stopped by the charge limit, and how many times the platform moved the run;
• if this Actor reports it: how many items to process worked or failed (ranges) and one failure reason from a fixed list;
• a short code made from the names of the input fields you set, never their values.