Bluesky scrapen 2026 (API & Python)

Bluesky ist die offenste Plattform in dieser Serie, und das darf man auch klar so sagen: Das AT Protocol, auf dem es läuft, wurde für Zero-Auth-Public-Reads entwickelt, es gibt hier also keine verschlossene Tür zu knacken. Die eigenen Entwickler-Docs bestätigen, dass sowohl die öffentliche AppView als auch die Netzwerk-Firehose für öffentliche Daten keine Authentifizierung brauchen, und Blueskys Nutzungsbedingungen enthalten überhaupt keine Einschränkung zu Scraping oder automatisiertem Zugriff. Dieser Guide behandelt den eigenen offenen Zugang des Protocols, No-Code-Tools und eine strukturierte API — und ist ehrlich dabei, dass der Wert der API hier nicht darin liegt, irgendetwas „aufzuschließen".

Warum Bluesky scrapen?

Blueskys öffentlicher Feed, Follower-Graphen und Threads speisen eine Handvoll wiederkehrender Use Cases:

• Social Listening und Trend-Tracking — nahezu in Echtzeit beobachten, was eine Marke, ein Thema oder ein Hashtag-ähnliches Keyword auf Bluesky auslöst.
• Creator- und Account-Recherche — Profil, Post-Verlauf und Follower-/Following-Zahlen eines Handles für Outreach oder Wettbewerbsrecherche abrufen.
• Conversation- und Thread-Analyse — den vollständigen Reply-Baum eines Posts lesen, um nachzuvollziehen, wie sich eine bestimmte Conversation entwickelt hat.
• Plattformübergreifender Social-Vergleich — Bluesky-Aktivität mit X/Twitter- oder Threads-Daten kombinieren, um zu sehen, wo eine Story oder ein Account wirklich ankommt.
• Trending-Topic-Monitoring — verfolgen, was plattformweit hochkommt, ohne selbst eine Keyword-Liste pflegen zu müssen.

Ist es legal, Bluesky zu scrapen?

Blueskys Nutzungsbedingungen (zuletzt aktualisiert am 14. August 2025) enthalten keine Einschränkung zu Scraping, Robots, Data-Mining oder automatisiertem Zugriff — eine Suche im ganzen Dokument findet keine Klausel, die zu diesen Begriffen passt. Das ist eine echte Abweichung von den meisten Plattformen in dieser Serie, wo eine Conditions-of-Use- oder Automated-Data-Collection-Terms-Seite Bots und Crawler ausdrücklich verbietet. Blueskys eigene Entwickler-Docs gehen noch weiter: Der API Hosts and Auth guide stellt klar fest, dass „viele Bluesky-Lexicon-Endpoints öffentlich sind und keine Authentifizierung brauchen", und dass auch die Netzwerk-Firehose „keine Auth braucht". Teile des Stacks — der Referenz-Client und ein Großteil des Kern-Codes des Protocols — sind laut dem Open-Source-Software-Abschnitt der Nutzungsbedingungen außerdem unter MIT- und Apache-Open-Source-Lizenzen veröffentlicht.

Das ist trotzdem kein Freibrief. Sammle nur, was öffentlich ist (private Accounts und DMs sind nie im Scope), behandle Handles, Bios und Post-Text dort, wo anwendbar, als personenbezogene Daten unter DSGVO/CCPA, und Blueskys Rate-Limits-Guide hält fest, dass die Limits der AppView „großzügig", aber real sind — anhaltender Missbrauch kann trotzdem gedrosselt werden. Siehe is web scraping legal für das größere Bild.

Option 1: Das AT Protocol direkt (und die echte Arbeit, die dabei anfällt)

Weil Blueskys Public Reads keine Auth brauchen, kannst du die AppView direkt mit einem einfachen HTTP-Request ansprechen — kein Key, keine Session, kein Login:

curl "https://public.api.bsky.app/xrpc/app.bsky.feed.getAuthorFeed?actor=bsky.app&limit=5"

Das ist der offene Zugang des Protocols selbst, der genau wie geplant funktioniert — app.bsky.feed.getAuthorFeed ist ein echter, dokumentierter Lexicon-Endpoint und liefert echte Post-Daten ohne jede Art von Credential. Anders als bei fast jedem anderen Guide in dieser Serie liegt die Reibung hier also nicht an Anti-Bot-Abwehr oder einer Login-Wall — für öffentliche Daten gibt es sie schlicht nicht. Die echte Arbeit zeigt sich erst, sobald du über einen einzelnen Lookup hinausgehst:

• Rohe AT-Protocol-Records, kein normalisiertes JSON. Jeder Lexicon-Endpoint liefert Records im Format seines eigenen Schemas (app.bsky.feed.post, app.bsky.actor.profile und so weiter), mit verschachtelten at://-URIs, CIDs und DIDs, die du selbst auflösen und flach klopfen musst, bevor die Daten downstream nutzbar sind.
• DID-Resolution ist ein eigenes Subsystem. Jeder Account und jeder Record ist über einen Decentralized Identifier (DID) referenziert, nicht über einen festen Usernamen — Handles können sich ändern, deshalb muss eine echte Pipeline DID-zu-Handle-Mappings auflösen und cachen, statt nur das gesuchte Handle zu speichern.
• Die Firehose ist die eigentliche Infrastruktur-Verpflichtung. Wenn du jeden öffentlichen Post netzwerkweit willst statt nur einen Account nach dem anderen, heißt das: com.atproto.sync.subscribeRepos konsumieren — ein WebSocket-Stream aus CBOR-codierten Repository-Updates — oder das leichtere JSON-Pendant Jetstream, und diesen Consumer durchgehend mit Cursor-Tracking, Reconnect-Logik und CBOR/MST-Decoding betreiben.
• Ein Protocol, ein Mental Model, nur für diese Plattform. Wenn deine Pipeline Reddit, TikTok, Instagram, X und Threads schon auf ein gemeinsames Schema normalisiert, ist AT Protocols Record-/Lexicon-/DID-Modell eine wirklich andere Form, die du daneben anbauen musst — offen, aber nicht dieselbe Form wie überall sonst, wo du Daten abholst.

Option 2: No-Code-Tools

Für Bluesky-Exports gibt es Marketplace-Scraper-Actors und Browser-Extensions, aber weil die zugrunde liegende API schon offen und keyless ist, sind die meisten davon nur dünne Wrapper um genau dieselben öffentlichen AppView-Endpoints von oben. Für einen einmaligen Profil-Pull oder einen Spreadsheet-Export sind sie in Ordnung, aber die eigentliche Lücke — normalisierte Felder über Plattformen hinweg und ein gepflegter Firehose-Consumer — lösen sie genauso wenig wie ein direkter Call der AppView.

Option 3: Eine strukturierte Bluesky-API (via Crawlora)

Wenn du Bluesky neben anderen Social-Plattformen in einer normalisierten Form willst — ein API-Key, ein JSON-Schema, keine Firehose-Infrastruktur zum Betreiben — liefert dir das eine Bluesky scraping API. Ein Profil nachschlagen:

curl "https://api.crawlora.net/api/v1/bluesky/profile?actor=bsky.app" \
  -H "x-api-key: $CRAWLORA_API_KEY"

{
  "code": 200,
  "msg": "OK",
  "data": {
    "did": "did:plc:z72i7hdynmk6r22z27h6tvur",
    "handle": "bsky.app",
    "display_name": "Bluesky",
    "description": "official Bluesky account",
    "avatar_url": "https://cdn.bsky.app/img/avatar/plain/did:plc:z72i7hdynmk6r22z27h6tvur/...",
    "banner_url": "https://cdn.bsky.app/img/banner/plain/did:plc:z72i7hdynmk6r22z27h6tvur/...",
    "followers_count": 34416262,
    "follows_count": 11,
    "posts_count": 804,
    "created_at": "2023-04-12T04:53:57.057Z",
    "indexed_at": "2025-10-27T21:05:26.152Z"
  }
}

Hol dir dann in Python den Feed eines Accounts und die Trending Topics der Plattform (echte Felder — sieh dir die docs an):

import requests
h = {"x-api-key": "YOUR_API_KEY"}
base = "https://api.crawlora.net/api/v1/bluesky"

profile = requests.get(f"{base}/profile", headers=h, params={"actor": "bsky.app"}).json()["data"]

feed = requests.get(f"{base}/author-feed", headers=h, params={"actor": "bsky.app", "limit": 25}).json()["data"]
for post in feed["posts"]:
    print(post["author"]["handle"], post["like_count"], post["text"])

trending = requests.get(f"{base}/trending-topics", headers=h).json()["data"]["topics"]

author-feed liefert jeden Post als normalisiertes JSON — kein at://-Parsing, kein CID-Handling:

{
  "data": {
    "posts": [
      {
        "uri": "at://did:plc:z72i7hdynmk6r22z27h6tvur/app.bsky.feed.post/3l6oveex3ii2l",
        "url": "https://bsky.app/profile/bsky.app/post/3l6oveex3ii2l",
        "author": { "did": "did:plc:z72i7hdynmk6r22z27h6tvur", "handle": "bsky.app", "display_name": "Bluesky" },
        "text": "Welcome to Bluesky!",
        "created_at": "2024-10-17T07:06:51.491Z",
        "reply_count": 8545,
        "repost_count": 9534,
        "like_count": 63579,
        "quote_count": 705
      }
    ],
    "cursor": "1234567890::bafyabc"
  }
}

trending-topics braucht außer dem API-Key keine Parameter und liefert eine flache, direkt anzeigbare Liste:

{
  "data": {
    "topics": [
      { "topic": "Big Brother 28", "link": "/profile/trending.bsky.app/feed/821933789" },
      { "topic": "NFL Preseason", "link": "/profile/trending.bsky.app/feed/821883116" }
    ],
    "suggested": [
      { "topic": "Popular with Friends", "link": "/profile/bsky.app/feed/with-friends" }
    ]
  }
}

/bluesky/search-actors (Parameter q) findet Accounts per Keyword, /bluesky/followers und /bluesky/follows liefern den Social Graph eines Actors mit cursor-basierter Pagination, und /bluesky/post-thread (Parameter uri) liefert einen Post plus seinen vollständigen verschachtelten Reply-Baum. Speichere eine Zeile pro Post oder Profil und lass es nach Zeitplan erneut laufen.

Was du sammeln kannst

Öffentliche Bluesky-Daten: Account-Suche per Keyword; vollständige Profile (Handle, DID, Display Name, Beschreibung, Avatar/Banner, Follower-/Follows-/Posts-Zahlen, Erstellungs- und Index-Timestamps); der Post-Feed eines Accounts (Text, Engagement-Zahlen, Sprache, Timestamps); Followers- und Follows-Listen; der vollständige verschachtelte Reply-Thread eines Posts; und plattformweite Trending Topics.

Grenzen und typische Herausforderungen

• Der Wert hier ist Convenience, nicht Zugang. Öffentliche Daten sind schon über das AT Protocol selbst offen — eine strukturierte API erspart dir Normalisierung und Firehose-Infrastruktur, nicht eine verschlossene Tür.
• Firehose/Jetstream ist eine echte Infrastruktur-Verpflichtung, wenn du diesen Weg gehst. Den netzwerkweiten Stream direkt zu konsumieren heißt, einen dauerhaften WebSocket-Consumer mit Cursor-Tracking und CBOR/MST-Decoding zu betreiben, kein Einmal-Skript.
• DIDs, keine festen Usernamen. Handles können sich ändern; der dauerhafte Identifier ist die DID, und eine echte Pipeline sollte beides auflösen und speichern.
• Cursor-basierte Pagination. Feeds, Followers und Follows paginieren alle über einen intransparenten cursor-Wert statt über eine Seitenzahl.
• Nur öffentliche Daten. Private Accounts, DMs und alles hinter einer Login-Wall sind bei jedem Ansatz hier außerhalb des Scopes und sollten das auch bleiben.

Wo das eingesetzt wird

• Social-Listening-Dashboards — Marken- oder Themen-Erwähnungen über öffentliche Posts hinweg nahezu in Echtzeit verfolgen.
• Creator-Recherche — Profil- und Post-Verlaufs-Lookups für Outreach oder die Prüfung von Partnerschaften.
• Conversation-Analyse — den vollständigen Reply-Baum eines viralen Posts abrufen, um nachzuvollziehen, wie sich ein Thread entwickelt hat.
• Plattformübergreifendes Monitoring — Bluesky-Aktivität mit X/Twitter- und Threads-Daten in einer Social-Listening-Pipeline kombinieren.

Sources

Leg los mit dem Sammeln

Probier es zuerst kostenlos aus: jage eine beliebige öffentliche URL durch den Free Web Scraper oder prüfe mit dem Anti-Bot Checker, ob eine Seite Bots blockiert — ohne Anmeldung.

Teste die profile-, author-feed- und search-Endpoints im Playground, sieh dir das Schema in den API docs an und wirf einen Blick aufs pricing. Bluesky zeigt dir, was auf dem neuesten großen offenen Social Network passiert; kombiniere es mit X/Twitter für die Daten des etablierten Platzhirschs und Threads für Metas Neueinsteiger, und du hast das vollständige Bild von „welche X-Alternative eine bestimmte Conversation tatsächlich für sich entschieden hat" in einem normalisierten Schema. Für dieselbe Konversation auf längerformigem, community-moderiertem Terrain deckt how to scrape Reddit die Threads ab, in denen ein Thema meist zuerst auftaucht. Siehe auch how to choose a web scraping API und is web scraping legal.