Cómo scrapear Bluesky en 2026 (API y Python)

Bluesky es la plataforma más abierta de esta serie, y vale la pena decirlo sin rodeos: el AT Protocol sobre el que corre se diseñó para lecturas públicas sin autenticación, así que aquí no hay ninguna puerta cerrada que forzar. Su propia documentación para desarrolladores confirma que tanto la AppView pública como la firehose de la red no requieren autenticación para datos públicos, y los Términos de Servicio de Bluesky no contienen ninguna restricción de scraping o acceso automatizado. Esta guía cubre el acceso abierto propio del protocolo, herramientas sin código y una API estructurada — y es honesta en que el valor de la API aquí no está en "desbloquear" nada.

¿Por qué scrapear Bluesky?

El feed público de Bluesky, los grafos de followers y los threads alimentan un puñado de casos de uso recurrentes:

• Social listening y seguimiento de tendencias — observar casi en tiempo real qué genera una marca, un tema o una palabra clave equivalente a un hashtag en Bluesky.
• Investigación de creadores y cuentas — traer el perfil, historial de posts y conteos de followers/follows de un handle para outreach o investigación competitiva.
• Análisis de conversaciones y threads — leer el árbol de respuestas completo de un post para entender cómo se desarrolló una conversación concreta.
• Comparación social entre plataformas — combinar la actividad de Bluesky con datos de X/Twitter o Threads para ver dónde realmente está aterrizando una historia o una cuenta.
• Monitoreo de temas en tendencia — rastrear qué está surgiendo en toda la plataforma sin mantener tú mismo una lista de palabras clave.

¿Es legal scrapear Bluesky?

Los Términos de Servicio de Bluesky (actualizados por última vez el 14 de agosto de 2025) no contienen ninguna restricción de scraping, robots, minería de datos o acceso automatizado — una búsqueda en todo el documento no encuentra ninguna cláusula que coincida con esos términos. Es una desviación genuina respecto a la mayoría de plataformas de esta serie, donde una página de Condiciones de Uso o Términos de Recolección Automatizada de Datos prohíbe explícitamente bots y crawlers. La propia documentación para desarrolladores de Bluesky va más allá: la guía de API Hosts and Auth afirma claramente que "muchos endpoints del Lexicon de Bluesky son públicos y no requieren autenticación", y que la firehose de la red tampoco "requiere auth". Partes del stack — el cliente de referencia, y buena parte del código central del protocolo — también se publican bajo licencias de código abierto MIT y Apache según la sección de Software de Código Abierto de los Términos.

Nada de eso es un cheque en blanco. Recolecta solo lo público (las cuentas privadas y los DMs nunca están dentro del alcance), trata los handles, bios y textos de posts como datos personales bajo GDPR/CCPA donde aplique, y la guía de rate limits de Bluesky señala que los límites de la AppView son "generosos" pero reales — el abuso sostenido igual puede hacer que te limiten. Consulta is web scraping legal para el panorama completo.

Opción 1: El AT Protocol directamente (y el trabajo real que implica)

Como las lecturas públicas de Bluesky no necesitan auth, puedes llamar a la AppView directamente con un simple request HTTP — sin key, sin sesión, sin login:

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

Eso es el acceso abierto propio del protocolo funcionando exactamente como se diseñó — app.bsky.feed.getAuthorFeed es un endpoint real y documentado del Lexicon, y devuelve datos de posts reales sin ninguna credencial. Así que, a diferencia de casi cualquier otra guía de esta serie, la fricción aquí no viene de defensas anti-bot ni de un muro de login — para datos públicos, sencillamente no existe. El trabajo real aparece en cuanto vas más allá de una única consulta:

• Records crudos del AT Protocol, no JSON normalizado. Cada endpoint del Lexicon devuelve records con la forma de su propio esquema (app.bsky.feed.post, app.bsky.actor.profile, etcétera), con URIs at://, CIDs y DIDs anidados que tienes que resolver y aplanar tú mismo antes de que los datos sean utilizables aguas abajo.
• La resolución de DID es un subsistema en sí mismo. Cada cuenta y cada record está identificado por un identificador descentralizado (DID), no por un nombre de usuario fijo — los handles pueden cambiar, así que un pipeline real necesita resolver y cachear los mapeos DID-a-handle, no solo guardar el handle que buscaste.
• La firehose es el verdadero compromiso de infraestructura. Si quieres cada post público en toda la red en lugar de una cuenta a la vez, eso significa consumir com.atproto.sync.subscribeRepos — un stream WebSocket de actualizaciones de repositorio codificadas en CBOR — o su hermano más ligero en JSON, Jetstream, y correr ese consumer continuamente con seguimiento de cursor, lógica de reconexión y decodificación CBOR/MST.
• Un protocolo, un modelo mental, solo para esta plataforma. Si tu pipeline ya normaliza Reddit, TikTok, Instagram, X y Threads en un solo esquema, el modelo de record/lexicon/DID del AT Protocol es una forma genuinamente distinta que hay que sumar al lado de las demás — abierta, pero no la misma forma que en ningún otro lugar de donde extraigas datos.

Opción 2: Herramientas sin código

Existen actors de scraping de marketplace y extensiones de navegador para exportar Bluesky, pero dado que la API subyacente ya es abierta y sin key, la mayoría son envoltorios delgados sobre los mismos endpoints públicos de la AppView descritos arriba. Están bien para una extracción puntual de perfil o una exportación a hoja de cálculo, pero no resuelven la brecha real — campos normalizados entre plataformas y un consumer de firehose mantenido — más de lo que lo hace llamar directamente a la AppView.

Opción 3: Una API estructurada de Bluesky (vía Crawlora)

Si quieres Bluesky junto a otras plataformas sociales en una única forma normalizada — una API key, un esquema JSON, sin infraestructura de firehose que operar — una Bluesky scraping API te da eso. Consulta un perfil:

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"
  }
}

Luego trae el feed de una cuenta y los temas en tendencia de la plataforma en Python (campos reales — revisa los docs):

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 devuelve cada post como JSON normalizado — sin parsear at://, sin manejo de CID:

{
  "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 no necesita ningún parámetro aparte de la API key y devuelve una lista plana, lista para mostrar:

{
  "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 (parámetro q) encuentra cuentas por palabra clave, /bluesky/followers y /bluesky/follows devuelven el grafo social de un actor con paginación basada en cursor, y /bluesky/post-thread (parámetro uri) devuelve un post y su árbol de respuestas completo y anidado. Guarda una fila por post o perfil y vuelve a ejecutarlo con un programa regular.

Qué puedes recolectar

Datos públicos de Bluesky: búsqueda de cuentas por palabra clave; perfiles completos (handle, DID, nombre para mostrar, descripción, avatar/banner, conteos de followers/follows/posts, timestamps de creación e indexación); el feed de posts de una cuenta (texto, conteos de engagement, idioma, timestamps); listas de followers y follows; el thread de respuestas completo y anidado de un post; y temas en tendencia en toda la plataforma.

Limitaciones y desafíos comunes

• El valor aquí es conveniencia, no acceso. Los datos públicos ya están abiertos a través del propio AT Protocol — una API estructurada te ahorra normalización e infraestructura de firehose, no una puerta cerrada.
• Firehose/Jetstream es un compromiso de infraestructura real si tomas ese camino. Consumir el stream de toda la red directamente significa operar un consumer WebSocket persistente con seguimiento de cursor y decodificación CBOR/MST, no un script puntual.
• DIDs, no nombres de usuario fijos. Los handles pueden cambiar; el identificador duradero es el DID, y un pipeline real debería resolver y guardar ambos.
• Paginación basada en cursor. Los feeds, followers y follows paginan todos mediante un valor cursor opaco en lugar de un número de página.
• Solo datos públicos. Las cuentas privadas, los DMs y todo lo que esté detrás de un muro de login quedan fuera del alcance de cualquier enfoque de esta guía, y deben seguir así.

Dónde se usa esto

• Dashboards de social listening — rastrear menciones de marca o tema en posts públicos casi en tiempo real.
• Investigación de creadores — búsquedas de perfil e historial de posts para outreach o evaluación de partnerships.
• Análisis de conversaciones — traer el árbol de respuestas completo de un post viral para entender cómo se desarrolló un thread.
• Monitoreo entre plataformas — combinar la actividad de Bluesky con datos de X/Twitter y Threads en un solo pipeline de social listening.

Sources

Empieza a recolectar

Pruébalo primero, gratis: pasa cualquier URL pública por el Free Web Scraper, o revisa si un sitio bloquea bots con el Anti-Bot Checker — sin registro.

Prueba los endpoints de profile, author-feed y search en el Playground, revisa el esquema en los API docs y consulta el pricing. Bluesky te muestra qué está pasando en la red social abierta más nueva y relevante; combínalo con X/Twitter para los datos del jugador establecido y Threads para el aspirante de Meta, y tienes el panorama completo de "qué alternativa a X realmente se llevó una conversación concreta" en un solo esquema normalizado. Para esa misma conversación en terreno más largo y moderado por la comunidad, how to scrape Reddit cubre los threads donde un tema suele aparecer primero. Consulta también how to choose a web scraping API e is web scraping legal.

Parte de nuestra how-to-scrape guide series — cada plataforma que cubrimos, en un solo índice.