Cómo scrapear Twitter (X) en 2026: métodos, herramientas y costos

Por Sorsa Editorial

Revisado por Keksich, fundador de Sorsa, especialista en marketing e investigador de la API de X.

Actualizado en julio de 2026: se verificó el estado de las librerías de código abierto contra GitHub y PyPI (twscrape, Scweet y Tweety funcionan; snscrape, Twint y ntscraper están muertas; la versión oficial de Twikit está rota y la comunidad la mantiene en un fork). El precio de pago por uso de la API de X y sus términos de servicio de enero de 2026 se revisaron de nuevo ese mismo mes.

Conclusión clave: En 2026 puedes scrapear datos públicos de Twitter (X) de tres formas: manejar un navegador headless y capturar las respuestas GraphQL internas de X, correr una librería de código abierto mantenida sobre una cuenta con sesión iniciada, o mandarle una URL a un scraper administrado. Las tres necesitan proxies residenciales, casi todas necesitan una cuenta y todas se rompen cada dos a cuatro semanas cuando X rota sus guest tokens y sus identificadores GraphQL. Una API de datos de solo lectura se salta todo eso y devuelve los mismos datos en JSON.

La mayoría de quienes buscan "cómo scrapear Twitter" no quiere un scraper en realidad. Quiere los datos. Son problemas distintos: los datos son la meta, y un scraper es un compromiso permanente con proxies residenciales, cuentas desechables que terminan baneadas y volver a hacerle ingeniería inversa a X cada par de semanas.

Nosotros construimos y operamos Sorsa API, una API de datos de Twitter/X de solo lectura, así que lee esta sección sabiendo que somos parte interesada. Aun así vale la pena decir la contrapartida sin rodeos, porque los mismos perfiles, tweets, resultados de búsqueda y seguidores que un scraper pelea por extraer regresan como JSON limpio desde una sola llamada REST, sin proxies, sin login y sin mantenimiento. El precio empieza desde $0.02 por cada 1,000 tweets y $0.01 por cada 1,000 perfiles en los endpoints por lotes, lo que la deja hasta 50 veces más barata que la API oficial de X, con el mismo límite de 20 solicitudes por segundo (20 req/s) en todos los planes. No hay solicitud ni cola de aprobación, la primera llamada toma unos tres minutos y las primeras 100 solicitudes son gratis, sin tarjeta.

Si de todas formas quieres construir el scraper, por control, por aprendizaje o porque tu flujo de trabajo de verdad lo necesita, esta guía es la versión honesta y vigente: qué datos son alcanzables, código de Python que funciona, qué herramientas viven y cuáles están muertas, cuánto cuesta en realidad y dónde caen las líneas legales.

Contenido

• ¿Todavía se puede scrapear Twitter en 2026?
• Qué datos puedes scrapear (y qué queda descartado)
• ¿Es legal scrapear Twitter?
• Cómo funciona X.com por dentro
• Método 1: scraping con navegador headless (con código)
• Método 2: librerías de Python de código abierto
• Método 3: scraping asistido por IA
• Método 4: servicios de scraping administrados
• Cómo encontrar URLs de tweets y perfiles para scrapear
• Lo que cuesta el scraping de verdad
• Método 5: una API de datos de solo lectura (sin scraping)
• ¿Qué método deberías usar?
• Preguntas frecuentes
• Cómo verificamos esta guía

¿Todavía se puede scrapear Twitter en 2026? {#can-you-still-scrape-twitter-in-2026}

Sí. Los datos públicos de Twitter siguen siendo scrapeables en 2026 sin la API oficial, pero todos los caminos fáciles se cerraron. Tres cambios explican la dificultad, y el resto de esta guía trata, en el fondo, de cómo darles la vuelta.

Primero, X blindó el acceso anónimo de invitado, que es el cambio que mató por sí solo al viejo stack gratuito. Segundo, movió la API oficial a pago por uso sin nivel gratuito de lectura, así que "usa la API y ya" ahora cuesta dinero desde la primera solicitud. Tercero, apretó la detección de bots en cada página pública, así que incluso un scraper funcional necesita proxies residenciales y un ritmo cuidadoso para sobrevivir.

La recompensa sigue siendo real. X es una de las fuentes más ricas de opinión pública en vivo que existen, y por eso los equipos lo siguen scrapeando para monitoreo de marca, análisis de sentimientos, investigación de competencia, generación de leads, detección de tendencias y datasets de machine learning. La dificultad es justo la razón por la que existe una guía así: el trabajo ya no está en parsear HTML, está en pasar primero las defensas.

Qué datos puedes scrapear (y qué queda descartado) {#what-data-can-you-scrape-and-what-is-off-limits}

Antes de escribir código, ubica dónde está el muro. Sin una sesión iniciada alcanzas perfiles públicos, tweets individuales con sus respuestas visibles y los metadatos de multimedia incrustada. Todo lo que vive detrás de la autenticación, cuentas protegidas, mensajes directos, listas completas de seguidores y resultados completos de búsqueda, queda fuera de alcance salvo que scrapees con una cuenta real, lo que trae riesgo de suspensión.

El acceso anónimo también trae límites más suaves. La profundidad de respuestas es corta, y las vistas de invitado con límite de tasa cortan las cronologías largas antes de que llegues al final. Los archivos históricos completos exigen una automatización pesada de desplazamiento, y aun así te topas con el tope de la cronología de invitado. Si necesitas historial sin scrapear, una API de datos puede devolver tweets desde 2006 mediante búsqueda, y las listas completas de seguidores y seguidos que ningún scraper anónimo puede tocar.

El resto de esta guía cubre solo la parte pública y sin autenticar. Esa es la línea más segura en lo legal y la que no te deja la cuenta baneada.

¿Es legal scrapear Twitter? {#is-it-legal-to-scrape-twitter}

Scrapear datos públicos de Twitter vive en una división real: los tribunales de Estados Unidos lo han protegido en su mayoría, mientras que los términos de servicio de X lo prohíben de plano. Ambas cosas son ciertas a la vez, y cuál te importa depende de si tu riesgo es de derecho penal o contractual.

Del lado de la jurisprudencia, la balanza se inclina hacia los datos públicos. En 2022 el Noveno Circuito confirmó en apelación que scrapear información disponible públicamente no viola la Ley de Fraude y Abuso Informático (CFAA), y la línea de casos hiQ v. LinkedIn es la más citada. X lo probó directamente y perdió: un tribunal federal desestimó X Corp. v. Bright Data en mayo de 2024, al considerar las demandas de X contra el scraper desplazadas en gran parte, y la demanda de X contra el Center for Countering Digital Hate se desestimó por motivos de la Primera Enmienda. Acceder a datos realmente públicos no es un delito bajo la CFAA.

Del lado contractual, los términos de X son la restricción más dura. Los términos vigentes, en efecto desde el 15 de enero de 2026, vetan rastrear o scrapear "en cualquier forma, para cualquier propósito" sin consentimiento previo por escrito. Añaden una cláusula de daños liquidados: quien solicite, vea o acceda a más de 1,000,000 de posts en cualquier periodo de 24 horas en violación de los términos acepta pagar $15,000 (o la misma cifra en euros en la UE, la EFTA y el Reino Unido) por cada millón de posts. La actualización de 2026 también redefine "Contenido" para cubrir prompts y salidas de IA, agrega una cláusula de uso indebido apuntada al jailbreaking y a la inyección de prompts, y fija una sede judicial en Texas con renuncia a la acción colectiva. Violar los términos es un asunto contractual, no un delito, pero X puede suspender cuentas, bloquear IPs y apoyarse en esa cláusula a escala.

Tres reglas mantienen el scraping público en terreno defendible: extrae solo datos públicos, nunca cuentas protegidas, mensajes directos ni nada detrás de un login; no acumules, conserva los datos scrapeados solo el tiempo que tu caso de uso necesite; y respeta los límites de tasa, porque sobrecargar servidores es donde el riesgo legal se vuelve concreto. En la UE hay una capa más, porque los posts públicos pueden contener datos personales, así que el RGPD se aplica en cuanto los almacenas o procesas. Esto es informativo, no es asesoría legal; si tu caso de uso involucra datos sensibles o alto volumen, habla con un abogado.

Cómo funciona X.com por dentro {#how-xcom-works-under-the-hood}

Entender la arquitectura de X explica por qué todo scraper termina rompiéndose. Si has scrapeado otros sitios, las defensas de X están en otra liga, y las razones son estructurales, no accidentales.

X es una aplicación de una sola página en React. Carga la URL de un perfil o un tweet y el servidor devuelve un cascarón HTML casi vacío. Después el JavaScript pide un guest token al backend y dispara consultas GraphQL para traer los datos reales, que el navegador renderiza. Casi no hay nada útil en el HTML inicial, así que el scraping simple de descargar y parsear no devuelve nada. Ese diseño le da a X tres cuellos de botella.

Los guest tokens son credenciales temporales requeridas en cada llamada GraphQL. Están atados a tu IP, vencen en unas horas y la forma en que se emiten cambia cada pocas semanas. Cuando X modifica la emisión de tokens, todo scraper que dependa del método viejo se detiene al instante. Este es exactamente el mecanismo que mató a las librerías gratuitas: todas asumían una ruta de acceso anónimo que ya no existe.

Los IDs de operación GraphQL (doc_ids) son identificadores incrustados en el bundle de JavaScript de X que le dicen al backend qué operación ejecutar. Obtener un perfil, buscar tweets y cargar una cronología necesitan uno distinto cada uno. X los rota cada dos a cuatro semanas, tienes que seguir de ocho a doce a la vez y no hay documentación, así que los sacas por ingeniería inversa del JavaScript minificado y lo repites quince días después. Un scraper manejado por navegador se salta esto porque deja que la página pida sus propios doc_ids vigentes.

Los límites de tasa y la detección son la tercera capa. X impone alrededor de 300 solicitudes por hora por IP en las sesiones de invitado. Las IPs de centro de datos quedan marcadas en una solicitud o dos. El fingerprinting de TLS atrapa a los navegadores headless cuya pila de red no imita perfectamente una real, y la validación de cookies marca patrones de sesión sospechosos. Si una cuenta que usas queda marcada, nuestro test de shadowban gratuito lo confirma en unos segundos.

Estas defensas no han sido estáticas. La tabla de abajo es un registro factual de qué cambió X y cuándo, que es la razón por la que una guía de scraping de apenas doce meses puede mandarte a herramientas muertas.

La conclusión es que X no es un objetivo estable. Publica cambios defensivos cada dos a cuatro semanas más o menos, y cualquier scraper es una suscripción a mantenerse al día.

Método 1: scraping con navegador headless (con código) {#method-1-headless-browser-scraping-with-code}

El enfoque casero más común automatiza un navegador real, carga páginas de X e intercepta las respuestas GraphQL que llevan los datos. Funciona porque ejecuta el mismo JavaScript que X espera, así que la página pide sus propios doc_ids vigentes y los datos renderizan como lo harían para una persona. Nunca tienes que rastrear los IDs de operación a mano.

Aquí hay un ejemplo mínimo en Python con Playwright que scrapea un solo tweet capturando la llamada de fondo a TweetResultByRestId:

from playwright.sync_api import sync_playwright
import json

def scrape_tweet(url: str) -> dict:
    xhr_calls = []

    def capture_response(response):
        if response.request.resource_type == "xhr":
            xhr_calls.append(response)

    with sync_playwright() as pw:
        browser = pw.chromium.launch(headless=True)
        page = browser.new_page()
        page.on("response", capture_response)
        page.goto(url)
        page.wait_for_selector("[data-testid='tweet']", timeout=15000)

        for xhr in xhr_calls:
            if "TweetResultByRestId" in xhr.url:
                data = xhr.json()
                return data["data"]["tweetResult"]["result"]

    return {}

tweet = scrape_tweet("https://x.com/elonmusk/status/1234567890")
print(json.dumps(tweet, indent=2))

El script lanza Chromium, navega a un tweet, espera a que renderice y luego filtra las llamadas XHR de fondo por la que trae los datos del tweet. Obtienes el objeto completo: texto, marcas de tiempo, conteos de engagement, URLs de multimedia y el perfil del autor. Los campos del tweet quedan anidados bajo una clave legacy, así que en producción conviene aplanar los que necesitas (texto, created_at, favorite_count, retweet_count, reply_count, view_count) en lugar de guardar el árbol crudo.

El mismo patrón sirve para otras superficies si buscas otra operación dentro de la URL del XHR: los perfiles usan UserByScreenName, la cronología de un usuario usa UserTweets y la búsqueda usa SearchTimeline (aunque la búsqueda necesita sesión iniciada). Para perfiles esperas a UserByScreenName en lugar del selector del tweet y lees el objeto de usuario de esa respuesta.

Lo que puedes obtener: perfiles públicos, tweets individuales, respuestas visibles, tweets citados y multimedia incrustada. En esencia, cualquier cosa de la interfaz pública.

Lo que no puedes obtener sin login: cuentas protegidas, mensajes directos, listas completas de seguidores y la búsqueda completa o las cronologías largas. El scraping autenticado sí llega ahí, pero arriesga baneos.

Lo que cuesta mantenerlo corriendo. Los proxies residenciales son innegociables, porque las IPs de centro de datos se bloquean casi al instante; presupuesta de $1 a $3 por gigabyte y de $50 a $200 al mes según el volumen. Necesitas suplantar el fingerprint, tamaños de viewport realistas y pausas aleatorizadas parecidas a las humanas, más lógica de reintento para tokens que vencen a media sesión y endpoints GraphQL que devuelven resultados vacíos cuando los doc_ids rotan. Esto funciona hoy y se romperá dentro de dos a cuatro semanas de la siguiente actualización de X, así que cuenta con diez a quince horas al mes para mantenerlo con vida.

Método 2: librerías de Python de código abierto {#method-2-open-source-python-libraries}

En lugar de construir desde cero, puedes usar una librería que envuelve la API interna de X. Unas se mantienen activamente y funcionan hoy; varias muy recomendadas están muertas; y una que era la opción por defecto ahora está rota en su versión oficial. Aquí está el panorama honesto, re-verificado contra GitHub y PyPI en julio de 2026.

La columna de estado es el punto entero de esta tabla, y se mueve. Twikit fue mucho tiempo la recomendación por defecto porque es async, está bien documentada y tenía la comunidad más grande, pero su versión publicada en PyPI se rompió con los cambios de webpack y de IDs de transacción que X hizo en 2026, y quienes la usaban se pasaron a un fork mantenido que conserva el mismo import twikit. Si un tutorial todavía te dice pip install twikit y da por hecho que funcionará, revisa primero la fecha y los issues abiertos. Para recolección de datos de solo lectura hoy, la opción más confiable es twscrape.

twscrape está hecha justo para este trabajo. Se autentica con tokens o cookies, guarda las sesiones en una base local y trae rotación multi-cuenta integrada, así que reparte las solicitudes entre un conjunto de cuentas y atraviesa los límites de tasa más rápido que una configuración de una sola cuenta. Un ejemplo de búsqueda desde su CLI es tan corto como twscrape search "from:xdevelopers lang:en" --limit=20, y la API de Python es equivalente. Las contrapartidas a tener en cuenta: es solo async, de solo lectura por diseño y no trae reanudación integrada, así que una extracción grande de varios días necesita tu propia lógica de checkpoints.

El cementerio (no pierdas tu tiempo)

Si un tutorial recomienda alguna de estas como solución vigente, su fecha es la pista. El panorama del scraping de X se renueva rápido, y por eso le ponemos fecha a la tabla de las que funcionan: una librería que servía el trimestre pasado puede estar muerta este.

La trampa con cada librería que funciona

Cada librería de la tabla vigente necesita una cuenta de X con sesión iniciada, y eso trae consecuencias. Nunca uses tu cuenta personal, porque X suspende las cuentas que muestran comportamiento automatizado y la verificación para cuentas nuevas de scraping se ha endurecido. Para cualquier volumen real necesitas varias cuentas dedicadas y un sistema de rotación, igual necesitas proxies residenciales, e incluso una librería mantenida activamente se rompe cuando X publica una actualización, momento en el que dependes del tiempo de respuesta de quien la mantiene o de que alguien la bifurque.

Método 3: scraping asistido por IA {#method-3-ai-assisted-scraping}

El scraping asistido por IA reemplaza los frágiles selectores CSS por un modelo de lenguaje que lee la página y extrae lo que describes en lenguaje natural. La opción de código abierto más conocida es ScrapeGraphAI, una librería de Python donde escribes un prompt como "obtén el texto, el autor y el conteo de likes de cada tweet" y ella deduce la estructura, luego se re-adapta cuando X cambia su diseño en lugar de romperse ante un elemento renombrado.

Es una respuesta real al problema de mantenimiento, con contrapartidas reales. El modelo todavía tiene que llegar a la página, así que cargas los mismos requisitos de proxies, cuenta y anti-bot que cualquier otro método, y el LLM no resuelve ninguno. Cada extracción también gasta tokens, lo que suma costo y latencia y hace la salida menos determinista que un parser fijo. Encaja para prototipar y para diseños que cambian seguido, y encaja mal para recolección barata, de alto volumen y repetible, donde quieres un costo predecible por registro. Si la meta es costo predecible y cero mantenimiento, una API de datos estructurada es la versión más limpia de lo que el scraping con IA intenta alcanzar.

Método 4: servicios de scraping administrados {#method-4-managed-scraping-services}

Los servicios administrados corren la infraestructura de scraping por ti. Envías una consulta o una URL, ellos devuelven datos estructurados, y la rotación de proxies, la gestión de tokens y el bypass anti-bot son su problema. Los nombres que compararás son Bright Data, Apify y Scrapfly, y Scweet también ofrece una versión alojada en Apify con un nivel gratuito chico. La ventaja es que no hay código que mantener ni proxies que administrar. Las desventajas son el costo a escala y la dependencia del proveedor: si su scraper se rompe, esperas su arreglo, y los modelos de precio van de por tweet a por unidad de cómputo a por gigabyte de tráfico de proxy, lo que hace difícil comparar el costo real por registro con el precio de lista.

Esta es una decisión lo bastante grande como para merecer su propio desglose. Para los costos reales por cada 1,000, la confiabilidad y las tarifas ocultas de cada opción administrada, consulta nuestra comparación de scrapers de Twitter.

Cómo encontrar URLs de tweets y perfiles para scrapear {#how-to-find-tweet-and-profile-urls-to-scrape}

Todos los métodos de arriba necesitan objetivos: las URLs concretas de tweets y perfiles que quieres extraer. La búsqueda propia de X está detrás del login, así que el rodeo práctico es Google, que sí indexa tweets públicos. Una consulta con site: suele ser la vía más rápida para armar una lista de objetivos sin cuenta.

Tres patrones cubren casi todo. site:x.com inurl:status <palabra clave> saca tweets individuales sobre un tema. site:x.com <nombre> encuentra las páginas de perfil de una persona o marca. Y las herramientas de rango de fechas de Google filtran las publicaciones recientes. La única salvedad honesta es que el índice de Google va horas o días detrás del tiempo real de X, así que para contenido de última hora no estará al día, pero para armar una lista de perfiles y publicaciones que vas a scrapear funciona bien. Si necesitas descubrimiento en tiempo real en lugar de una lista estática, ahí es justo donde buscar por consulta le gana a rastrear, y una API de búsqueda devuelve los tweets que coinciden directamente.

Lo que cuesta el scraping de verdad {#what-scraping-actually-costs}

La mayoría de los tutoriales cita el precio de lista de la herramienta y ahí se detiene. El costo real de scrapear X es la herramienta más los proxies residenciales más el tiempo de desarrollo más el costo recurrente de que las cosas se rompan. Aquí está el panorama completo de todas las rutas.

La fila que lo decide es el mantenimiento. El tiempo de desarrollo es la línea más cara de la lista, y no aparece hasta la primera vez que X rota sus doc_ids y tu pipeline se queda mudo un viernes. Los equipos con los que hemos trabajado gastan rutinariamente de diez a quince horas al mes manteniendo con vida un scraper de X hecho en casa, más la factura de proxies encima. Como referencia de escala, extraer 10,000 tweets por automatización de navegador usa alrededor de 50 a 100 solicitudes y unos cuantos dólares de tráfico de proxies residenciales, antes de contar las horas. Las herramientas gratuitas no salen gratis una vez que sumas tu propio tiempo.

Método 5: una API de datos de solo lectura (sin scraping) {#method-5-a-read-only-data-api-no-scraping}

Si llegaste hasta aquí, la conclusión honesta es que scrapear X es posible pero costoso en tiempo, dinero y esfuerzo continuo, y para muchos casos de uso no necesitas scrapear en absoluto. Una API de datos de X de solo lectura devuelve la misma información por endpoints REST simples: perfiles, tweets, búsqueda, seguidores, engagement y datos de comunidades, todo como JSON limpio, una clave API en el encabezado, sin proxies, sin guest tokens y sin doc_ids.

Aquí hay una consulta de perfil con la API de Sorsa:

curl -H "ApiKey: YOUR_KEY" \
  "https://api.sorsa.io/v3/info?username=elonmusk"

Eso devuelve el objeto completo del perfil en una línea: ID, nombre de usuario, nombre visible, bio, conteos de seguidores y seguidos, número de tweets, estado de verificación, imágenes y fecha de creación. Compáralo con las más de 20 líneas de Playwright de arriba, más la configuración de proxies, la gestión de tokens y la lógica de reintento que ese ejemplo ni siquiera muestra.

Sorsa cubre 40 endpoints entre usuarios, tweets, búsqueda, seguidores, verificación, comunidades, listas y tendencias, con un límite fijo de 20 solicitudes por segundo y sin ventanas por endpoint. El precio empieza desde $0.02 por cada 1,000 tweets y $0.01 por cada 1,000 perfiles en los endpoints por lotes, donde llamadas como /info-batch (hasta 100 perfiles) y /tweet-info-bulk (hasta 100 tweets) cuentan cada una como una sola solicitud. Las primeras 100 solicitudes son gratis, sin tarjeta, puedes probar cualquier endpoint sin código en el playground, y el inicio rápido de tres minutos deja funcionando una primera llamada sin aprobación. Si vienes de la API oficial de X, la guía de migración mapea el cambio endpoint por endpoint.

La contrapartida es real y vale la pena nombrarla: una API es de solo lectura, así que no publica, no da likes ni sigue cuentas, y dependes del proveedor en vez de tu propio código. Para trabajo intensivo en lecturas que tiene que seguir corriendo, eso suele ser justo el punto.

En la práctica: un pipeline de monitoreo que dejó de romperse

Un equipo mediano de analítica fintech llegó a nosotros con un scraper casero de Playwright para monitoreo en tiempo real sobre unos cientos de cuentas de finanzas y de la competencia. Funcionaba hasta que dejaba de funcionar: cada vez que X rotaba sus doc_ids el pipeline se quedaba mudo, y un ingeniero perdía un día haciéndole ingeniería inversa a los nuevos identificadores y rotando proxies. Entre horas de desarrollo y proxies residenciales, el costo mensual real había trepado por encima de $2,000 por datos que trataban como rutina.

Movieron el lado de lectura a una API de datos y siguieron construyendo solo las partes que de verdad eran suyas. El desgaste recurrente de ingeniería se fue a cero, porque las mismas llamadas REST devolvían el mismo JSON cada día sin importar qué cambiara X de su lado, y el gasto bajó a una fracción del total de proxies más horas. La reducción de costo es una propiedad real de pasar del scraping por cuenta con proxies a la tarifa plana por solicitud; la reducción de mantenimiento es simplemente lo que ocurre cuando dejas de correr un scraper. Mantuvimos el ejemplo anónimo porque nombrar a un cliente y sus objetivos de monitoreo puede exponer a ambos.

¿Qué método deberías usar? {#which-method-should-you-use}

No hay un ganador único. La elección correcta depende de tu volumen, tu presupuesto y cuántas caídas puedes tolerar.

Scrapea con un navegador headless cuando quieras control total de la extracción, estés aprendiendo scraping como habilidad o tu flujo de trabajo sea de verdad a la medida y ninguna herramienta lo cubra. Usa una librería de código abierto cuando quieras un arranque más rápido que hacerlo tú mismo y aceptes el riesgo de baneo de cuentas y el mantenimiento. Usa un scraper administrado cuando quieras delegar la infraestructura y el uptime te importe más que el costo. Usa una API de datos de solo lectura cuando necesites acceso de lectura confiable, no puedas permitirte fallas semanales o estés lanzando un producto sobre datos de X. Y quédate en la API oficial de X para todo lo que escriba, publicar, mensajes directos y seguir cuentas, porque ningún scraper ni API de lectura hace operaciones de escritura con seguridad, además de los datos de Ads y de cumplimiento.

Para una mirada más amplia a proveedores, consulta nuestra guía de alternativas a la API de Twitter/X; para lo que cuesta hoy la API oficial, nuestro desglose de precios de la API de X; y si te preguntas si el nivel gratuito sobrevivió, si la API de Twitter es gratis en 2026.

Preguntas frecuentes {#faq}

¿Todavía se puede scrapear Twitter en 2026?

Sí, los datos públicos de Twitter siguen siendo scrapeables en 2026 sin la API oficial, pero los caminos fáciles ya no están. Las librerías gratuitas que dependían del acceso anónimo están muertas, la navegación como invitado tiene límite de tasa y X rota sus guest tokens internos y sus identificadores GraphQL cada dos a cuatro semanas. Los métodos que funcionan hoy son la automatización con navegador headless, una librería de código abierto mantenida sobre una cuenta con sesión iniciada, un scraper administrado o una API de datos de solo lectura.

¿Se puede scrapear Twitter sin iniciar sesión?

Puedes, pero con límites fuertes. Sin autenticación, el scraping con navegador headless llega a perfiles públicos y tweets individuales, mientras que la búsqueda completa, las cronologías completas, los hilos profundos y las listas de seguidores quedan restringidos o bloqueados. Toda librería de código abierto que da acceso completo a los datos requiere credenciales de cuenta o tokens de sesión, que es lo que desbloquea los datos completos.

¿Cuál es la mejor herramienta para scrapear Twitter en 2026?

Depende de tu trabajo. Para recolección de datos de solo lectura a alto volumen, twscrape es la librería mantenida más confiable, con rotación multi-cuenta integrada. Scweet y Tweety también funcionan. La versión oficial de Twikit está rota por los cambios de X de 2026 y funciona a través de un fork de la comunidad, así que verifica su estado antes de apoyarte en ella. Para acceso sin mantenimiento, sin proxies ni cuentas baneadas, una API de datos de solo lectura como Sorsa devuelve los mismos datos por endpoints REST, desde $0.02 por cada 1,000 tweets con las primeras 100 solicitudes gratis.

¿Se puede scrapear Twitter con Python?

Sí, Python es el lenguaje más común para esto. Puedes manejar un navegador headless con Playwright y capturar las respuestas GraphQL de X, o usar una librería: twscrape para cosecha de datos multi-cuenta, Scweet para un enfoque de cookies más GraphQL, o Tweety para extracciones ligeras. Tweepy también existe, pero envuelve la API oficial de pago en lugar de scrapear. Si una API encaja mejor que un scraper, nuestra guía de la API de Twitter con Python recorre la ruta REST.

¿Es legal scrapear Twitter?

Scrapear datos genuinamente públicos es legal en general en Estados Unidos, porque los tribunales han determinado que acceder a datos web públicos no viola la Ley de Fraude y Abuso Informático. Aun así puede incumplir los términos de servicio de X, que es un asunto contractual y no un delito, y puede costarte el baneo de una cuenta o una IP. Acceder a datos no públicos sí cruza la línea de la CFAA. En la UE, el RGPD se aplica cuando los posts públicos contienen datos personales que almacenas o procesas. Esto es informativo, no es asesoría legal.

¿La API oficial de X todavía tiene nivel gratuito?

No. X descontinuó el nivel gratuito y pasó a un precio de pago por uso para nuevos desarrolladores. Compras créditos por adelantado y pagas por recurso: unos $0.005 por lectura de post, $0.010 por perfil de usuario y $0.015 por post creado, con un tope de 2 millones de lecturas de posts al mes en cuentas estándar. Nuestra guía complementaria sobre si la API de X es gratis cubre las opciones vigentes.

¿Cada cuánto rompe X a los scrapers?

Cada dos a cuatro semanas en promedio. Los disparadores usuales son cambios en cómo se emiten los guest tokens, rotaciones de los IDs de operación GraphQL y nuevas capas de detección anti-bot. Cualquier scraper, casero o basado en una librería, necesita actualizaciones regulares para seguir funcionando, y este mantenimiento recurrente es el mayor costo oculto del enfoque de scraping.

Cómo verificamos esta guía {#how-we-verified-this-guide}

Esta guía se construye sobre nuestro propio trabajo operando una API de datos de X y probando contra los endpoints en vivo de X, más una revisión fresca del estado actual de cada herramienta. En esta pasada revisamos de nuevo las librerías de código abierto directamente en GitHub y PyPI para confirmar qué se mantiene (twscrape, Scweet y Tweety están activas en 2026; snscrape, Twint y ntscraper no; la versión oficial de Twikit está rota y funciona a través de un fork de la comunidad), leímos los términos de servicio de X en efecto desde el 15 de enero de 2026 por el lenguaje sobre scraping y daños liquidados, y usamos el resumen de la EFF del fallo del Noveno Circuito sobre la CFAA para la sección de jurisprudencia. El precio de nuestra propia API sale de los docs de Sorsa. Los términos de servicio de X y el precio de la API oficial de X se re-verificaron en julio de 2026; el desglose de librerías de código abierto se probó ese mismo mes. Las librerías y los términos de las plataformas cambian rápido, así que vuelve a revisar cualquier cosa sensible al tiempo contra la fuente antes de apoyarte en ella.