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, logins ni mantenimiento de tu lado. 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, qué implica cada enfoque, 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
• 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?

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 se topa rápido con bloqueos de IP y límites de tasa.

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 seguirle el paso a controles de acceso que cambian cada pocas semanas.

Qué datos puedes scrapear (y qué queda descartado)

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.

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?

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

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, un scraper sigue de ocho a doce a la vez y no hay documentación, así que quienes mantienen scrapers los sacan por ingeniería inversa del JavaScript minificado y lo repiten quince días después.

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

El enfoque casero más común automatiza un navegador real, carga páginas de X y lee los datos que la propia página solicita. Funciona porque ejecuta el mismo JavaScript que X espera, así que la página pide sus propios doc_ids vigentes y el contenido renderiza como lo haría para una persona.

En la práctica, el scraper lanza un Chromium headless, navega a un tweet o a un perfil, espera a que renderice y lee el objeto del tweet de las respuestas de fondo de la propia página: texto, marcas de tiempo, conteos de engagement, URLs de multimedia y el perfil del autor, anidados bajo una clave legacy que el código de producción después aplana en el puñado de campos que necesita. Los perfiles, las cronologías y la búsqueda siguen el mismo patrón, aunque la búsqueda y las cronologías largas están detrás de un login.

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 pone la cuenta en riesgo.

Lo que cuesta mantenerlo corriendo. Las IPs de centro de datos se bloquean casi al instante, así que un scraper de navegador solo sobrevive con tráfico de proxies residenciales, típicamente de $50 a $200 al mes según el volumen, y necesita lógica de reintento constante para tokens que vencen a media sesión y para endpoints 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

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.

twscrape es la más citada de las librerías mantenidas. 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, y como toda librería de la tabla depende de una cuenta de X que X puede suspender.

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. X suspende las cuentas que muestran comportamiento automatizado, así que la cuenta detrás del scraper siempre está en riesgo, 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

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

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 las medidas 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

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

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)

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, y sin proxies, guest tokens ni doc_ids que tengas que gestionar.

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 un script de automatización de navegador más la configuración de proxies, la gestión de tokens y la lógica de reintento que lo rodean.

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?

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

Construir tu propio scraper, con un navegador headless o una librería de código abierto, te da control total de la extracción a cambio de riesgo de baneo de cuentas, gasto en proxies y mantenimiento cada vez que X cambia algo. Un scraper administrado traslada esa infraestructura a un proveedor, a un precio más alto y con dependencia de sus arreglos. 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

¿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. Entre las librerías de código abierto, twscrape, Scweet y Tweety seguían mantenidas en julio de 2026, mientras que 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. Todas necesitan una cuenta de X con sesión iniciada y arreglos periódicos. Para acceso sin mantenimiento, sin proxies de tu lado ni riesgo para tu cuenta, 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, ya sea con automatización de navegador headless con Playwright o con una de las librerías mantenidas (twscrape, Scweet, Tweety), cada una de las cuales necesita una cuenta con sesión iniciada y se rompe cuando X cambia. 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

Esta guía se construye sobre nuestro propio trabajo operando una API de datos 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 re-verificó 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.