Por Sorsa Editorial

Actualizado en julio de 2026: agregada la opción inicial de 100 solicitudes gratis, reformulado el precio de Sorsa en torno a la tarifa por cada 1,000 perfiles, y refrescados los costos de la API oficial de X a la tarjeta de tarifas por recurso vigente.

Conclusión clave: La API de seguidores de Twitter/X recupera las cuentas que siguen a un usuario y las cuentas que ese usuario sigue. La API oficial de X expone GET /2/users/:id/followers y GET /2/users/:id/following, devolviendo objetos de usuario paginados con metadatos de perfil completos. Cada endpoint cobra por objeto de usuario devuelto, así que el costo de una lista de seguidores escala con el tamaño de la cuenta.

Si alguna vez has intentado extraer una lista de seguidores de X (antes Twitter) a cualquier escala significativa, te has topado con uno de dos muros. O bien la UI web deja de cargar en silencio después de unos cientos de perfiles, o te registras en la API oficial de X y descubres que «obtener 100,000 seguidores» puede significar una factura de cuatro cifras. Ninguno es viable para los trabajos para los que la gente realmente necesita datos de seguidores: inteligencia competitiva, generación de leads, descubrimiento de influencers, investigación académica, verificación de campañas.

Este es el recorrido orientado a desarrolladores: los endpoints, el modelo de autenticación, los patrones de producción. Si aún no has elegido una herramienta y quieres sopesar el acceso por API contra las extensiones de navegador, los scrapers caseros y la exportación nativa de datos de X, nuestra comparación de métodos para extraer seguidores de Twitter cubre esos trade-offs primero. El resto de esta guía asume que ya te decidiste por la ruta de la API.

Sorsa API, un proveedor alternativo de API de Twitter/X, maneja los mismos datos que los endpoints oficiales con una estructura de costo diferente. Sus endpoints /followers y /follows devuelven hasta 200 perfiles de usuario completos por solicitud detrás de un solo encabezado ApiKey, corren a 20 solicitudes por segundo sin revisión de app, y cobran por solicitud en lugar de por objeto de usuario. Esa última diferencia es toda la historia para los datos de seguidores a escala, y las secciones de abajo desarrollan por qué, con los endpoints oficiales, el cálculo del precio, y Python y JavaScript listos para copiar y pegar.

Tabla de contenidos

  1. Qué devuelve la API de seguidores de Twitter
  2. ¿Cuánto cuesta la API oficial de X para seguidores en 2026?
  3. Cobro por recurso vs cobro por solicitud
  4. Los endpoints de seguidores y de seguidos de Sorsa
  5. Obtener una página de seguidores
  6. Paginar a través de una lista completa de seguidores
  7. Patrones de producción que importan a escala
  8. Por qué /verified-followers existe como endpoint separado
  9. Casos límite que te harán tropezar
  10. Cuándo la API oficial de X todavía tiene sentido
  11. Preguntas frecuentes
  12. Cómo empezar

Qué devuelve la API de seguidores de Twitter {#what-the-twitter-followers-api-returns}

La API de seguidores de Twitter/X devuelve una lista paginada de objetos de usuario, uno por seguidor, con cada objeto cargando el perfil completo de ese seguidor en lugar de solo un usuario. Una solicitud de seguidor es, en la práctica, una consulta masiva de perfiles con un filtro de relación aplicado. Por cada seguidor típicamente obtienes los mismos campos que obtendrías de una consulta de perfil directa.

  • ID numérico de usuario estable y usuario actual
  • Nombre para mostrar, bio, URL de imagen de perfil, URL de banner
  • Conteo de seguidores, conteo de seguidos, conteo de tweets
  • Fecha de creación de la cuenta
  • Cadena de ubicación (texto libre, no validada)
  • Estado de verificación (Azul, Dorada, Gris)
  • Bandera de protegida/privada
  • URLs encontradas en la bio
  • IDs de tweets fijados

Esa riqueza importa más de lo que parece. Con una solicitud de lista de seguidores no solo estás recolectando usuarios; estás obteniendo los datos necesarios para calificar, segmentar o filtrar la audiencia sin una segunda ronda de consultas de perfil.

La API oficial de X divide esto en dos endpoints:

EndpointDevuelve
GET /2/users/:id/followersUsuarios que siguen al usuario especificado
GET /2/users/:id/followingUsuarios que el usuario especificado sigue

Sorsa expone el mismo par como GET /v3/followers y GET /v3/follows, más un tercer endpoint utilitario, GET /v3/verified-followers, que devuelve solo cuentas verificadas (más sobre por qué existe abajo).

¿Cuánto cuesta la API oficial de X para seguidores en 2026? {#how-much-does-the-official-x-api-cost-for-followers-in-2026}

Bajo el modelo de pago por uso de la API de X, las lecturas de seguidores y de seguidos se cobran por objeto de usuario devuelto, a $0.010 por recurso para cualquier cuenta que no sea la tuya. Una lista de seguidores de 100,000 cuentas son 100,000 recursos facturables, aproximadamente $1,000, sin importar cuán pocas solicitudes usaste para paginarla. Este es el detalle que la mayoría de las guías más viejas pasan por alto, porque fueron escritas antes de los cambios de precio de 2026.

El modelo llegó en dos pasos. X pasó al pago por uso como opción por defecto para los desarrolladores nuevos en febrero de 2026: sin nivel gratuito, sin suscripción fija Basic o Pro, solo créditos comprados en la Developer Console y cobrados por llamada. Luego, el 20 de abril de 2026, X recortó las «Owned Reads» (solicitudes de los datos de tu propia cuenta) a $0.001 por recurso, mientras que las lecturas de cualquier otra cuenta se mantuvieron a la tarifa estándar. Según la comunidad de desarrolladores de X, se te cobra por recurso: una cuenta de usuario con 1,000 seguidores a $0.010 cada uno suma $10, cobrado por objeto de usuario devuelto, no por solicitud.

Este es el truco con las «Owned Reads». Extraer la lista de seguidores de tu propia cuenta de desarrollador ahora es barato. Extraer los seguidores de un competidor, un influencer, o una fuente de leads es la lectura no propia estándar, cobrada por objeto de usuario. El tope de 2 millones al mes que X aplica a las lecturas de publicación no gobierna las lecturas de seguidores, que se cobran puramente por recurso.

Tamaño de la cuentaAPI oficial de X (lecturas no propias, $0.010/recurso)Sorsa API (Pro)
1,000 seguidores$10.00~$0.01
10,000 seguidores$100.00~$0.10
100,000 seguidores$1,000.00~$1.00
1,000,000 seguidores$10,000.00~$10.00

Divulgación: Sorsa API es nuestro producto. Las cifras de la API oficial usan el precio publicado de X, donde las lecturas no propias se cobran por recurso devuelto y las lecturas propias son $0.001 por recurso, a la tarifa de lectura de usuario de $0.010 por recurso vigente a junio de 2026; tu costo exacto puede variar con el manejo de excedentes y cualquier contrato negociado. Recomendamos probar cualquier proveedor contra tu carga de trabajo real antes de comprometerte.

Cobro por recurso vs cobro por solicitud {#per-resource-vs-per-request-billing}

La diferencia entre el cobro por recurso y el cobro por solicitud es lo que decide el costo de los datos de seguidores, no la tarifa anunciada. La API oficial de X cuenta cada objeto de usuario en una respuesta como un recurso facturable separado, así que una solicitud que devuelve 1,000 seguidores cuesta lo mismo que 1,000 consultas individuales. Una API de tarifa plana como Sorsa cuenta toda la solicitud como una unidad contra una cuota mensual, sin importar cuántos usuarios regresen en ella.

Para la extracción de seguidores este hueco se acumula rápido, porque los endpoints de seguidores devuelven muchos objetos por llamada. En la API oficial, una lista de 100,000 seguidores son 100,000 recursos a $0.010 cada uno. En Sorsa, la misma lista son aproximadamente 500 solicitudes (200 perfiles por solicitud) contra una cuota mensual, alrededor de $1.00 en el plan Pro. La forma de los datos es la misma; la unidad por la que pagas no.

Esta es la razón estructural por la que existe un mercado de API de Twitter de terceros para los datos de seguidores. La API oficial tiene buen precio cuando solo lees tu propia cuenta. Para todo lo demás, el cobro por recurso juega en tu contra, y un modelo por solicitud es la palanca que baja el costo. Para el desglose completo entre proveedores, revisa nuestra guía de precios de la API de Twitter.

Los endpoints de seguidores y de seguidos de Sorsa {#the-sorsa-follower-and-following-endpoints}

Los endpoints de seguidores de Sorsa son tres solicitudes GET autenticadas con un solo encabezado ApiKey, sin flujo OAuth, sin revisión de app, y sin rotación de token bearer. La documentación completa de seguidores y seguidos cubre el esquema de respuesta y el comportamiento de paginación a fondo. La versión corta:

  • GET /v3/followers devuelve las cuentas que siguen al usuario especificado.
  • GET /v3/follows devuelve las cuentas que el usuario especificado está siguiendo.
  • GET /v3/verified-followers devuelve la misma forma que /followers, pero solo cuentas verificadas Azul, Dorada y Gris.

Pasas uno de tres identificadores de usuario como parámetro de consulta, más un cursor de paginación opcional:

ParámetroDescripción
usernameUsuario sin @, por ejemplo stripe
user_idID numérico de usuario, por ejemplo 44196397
user_linkURL de perfil completa, por ejemplo https://x.com/stripe
next_cursorCursor de paginación opcional devuelto por una respuesta previa

Cada página devuelve hasta 200 objetos de usuario, entre los rendimientos por solicitud más altos disponibles. La API oficial de X limita cada llamada a 1,000 objetos de usuario pero cobra por cada uno de ellos; Sorsa devuelve 200 por solicitud y cuenta todo el lote como una sola solicitud contra tu cuota.

Obtener una página de seguidores {#fetching-one-page-of-followers}

La llamada funcional más pequeña contra el endpoint /followers es un solo HTTP GET con un usuario y tu clave API. Una solicitud, una respuesta, sin baile de autenticación.

cURL

bash
curl "https://api.sorsa.io/v3/followers?username=stripe" \
  -H "ApiKey: YOUR_API_KEY"

Python

python
import requests

resp = requests.get(
    "https://api.sorsa.io/v3/followers",
    headers={"ApiKey": "YOUR_API_KEY"},
    params={"username": "stripe"},
)
for user in resp.json().get("users", []):
    print(f"@{user['username']} - {user.get('description', '')[:80]}")

JavaScript (Node.js o navegador)

javascript
const resp = await fetch(
  "https://api.sorsa.io/v3/followers?username=stripe",
  { headers: { "ApiKey": "YOUR_API_KEY" } }
);
const { users } = await resp.json();
users.forEach((u) =>
  console.log(`@${u.username} - ${u.description?.slice(0, 80) ?? ""}`)
);

Para obtener las cuentas que un usuario sigue en su lugar, cambia /followers por /follows. La forma del parámetro y la estructura de respuesta son idénticas. Si quieres ver la respuesta antes de escribir código, la herramienta Recent Followers renderiza los últimos 20 seguidores de cualquier cuenta pública en tu navegador, y el API Playground te deja llamar a cualquier endpoint sin escribir una línea.

Paginar a través de una lista completa de seguidores {#paginating-through-a-complete-follower-list}

Para recuperar una lista de seguidores más allá de la primera página, recorres las páginas usando el valor next_cursor devuelto en cada respuesta, pasándolo de vuelta en la siguiente solicitud hasta que regrese null o ausente. Una solicitud devuelve hasta 200 usuarios en Sorsa, así que una lista completa es un bucle sobre esas páginas.

Aquí hay un bucle completo, con forma de producción, en Python. Maneja la paginación, el límite de tasa, y un tope duro de páginas para que una extracción desbocada no drene silenciosamente tu cuota:

python
import requests
import time

API_KEY = "YOUR_API_KEY"

def get_all_followers(username, max_pages=100):
    """Fetch the complete follower list of a public account."""
    all_users = []
    cursor = None

    for page in range(max_pages):
        params = {"username": username}
        if cursor:
            params["next_cursor"] = cursor

        resp = requests.get(
            "https://api.sorsa.io/v3/followers",
            headers={"ApiKey": API_KEY},
            params=params,
            timeout=30,
        )
        resp.raise_for_status()
        data = resp.json()

        users = data.get("users", [])
        all_users.extend(users)
        print(f"Page {page + 1}: {len(users)} followers (total: {len(all_users)})")

        cursor = data.get("next_cursor")
        if not cursor:
            print("Reached end of list.")
            break

        # Sorsa's rate limit is 20 req/s. 50ms between calls is safe.
        time.sleep(0.05)

    return all_users


followers = get_all_followers("stripe", max_pages=100)
print(f"\nTotal followers collected: {len(followers)}")

Al límite de tasa de 20 solicitudes por segundo, esto equivale a aproximadamente 4,000 seguidores por segundo de tiempo de reloj. Una cuenta de 100,000 seguidores toma unos 25 segundos. Una cuenta de un millón de seguidores toma unos cuatro minutos. El mismo patrón de cursor aplica a todos los demás endpoints paginados de la API.

Para una lista de seguidos, cambia /followers por /follows; todo lo demás se mantiene idéntico. Un ayudante unificado que maneja ambos:

python
def get_user_graph(username, endpoint, max_pages=100):
    """endpoint should be 'followers' or 'follows'."""
    all_users = []
    cursor = None
    for _ in range(max_pages):
        params = {"username": username}
        if cursor:
            params["next_cursor"] = cursor
        data = requests.get(
            f"https://api.sorsa.io/v3/{endpoint}",
            headers={"ApiKey": API_KEY},
            params=params,
            timeout=30,
        ).json()
        all_users.extend(data.get("users", []))
        cursor = data.get("next_cursor")
        if not cursor:
            break
        time.sleep(0.05)
    return all_users

Patrones de producción que importan a escala {#production-patterns-that-matter-at-scale}

Un bucle ordenado funciona en un notebook. Correr la extracción de seguidores dentro de un pipeline real (cron jobs, barridos de múltiples cuentas, enriquecimiento posterior) hace emerger un conjunto de problemas diferente. Estos son los patrones a los que recurrimos una vez que el bucle básico funciona.

Maneja la respuesta 429 de forma limpia

Sorsa devuelve 429 Too Many Requests cuando superas el límite de 20 solicitudes/s. El arreglo es corto: espera un segundo, reintenta. No hay penalización por chocar el límite y no hay token bucket que recorrer. Un envoltorio listo para usar:

python
import time
import requests

def get_with_retry(url, params, headers, max_retries=5):
    for attempt in range(max_retries):
        resp = requests.get(url, params=params, headers=headers, timeout=30)
        if resp.status_code == 429:
            # Rate limited. Back off and retry.
            time.sleep(1.0 + attempt * 0.5)
            continue
        if resp.status_code >= 500:
            # Transient server error. Exponential backoff.
            time.sleep(2 ** attempt)
            continue
        resp.raise_for_status()
        return resp.json()
    raise RuntimeError(f"Failed after {max_retries} retries")

Si tu bucle ya duerme 50ms entre llamadas, rara vez verás un 429. Aparecen sobre todo cuando paralelizas entre cuentas. Los docs de límites de tasa describen exactamente qué cuenta contra la cuota.

Usa user_id en lugar de username para trabajos de larga duración

Los usuarios cambian; el user_id numérico no. Si programas un trabajo para re-extraer los seguidores de las mismas cuentas cada semana, resuelve cada usuario a un user_id una vez y guárdalo. De lo contrario, un objetivo que se renombra rompe silenciosamente el pipeline, y tus logs dicen «user not found» sin causa obvia.

python
def resolve_user_id(username):
    resp = requests.get(
        f"https://api.sorsa.io/v3/username-to-id/{username}",
        headers={"ApiKey": API_KEY},
        timeout=30,
    )
    resp.raise_for_status()
    return resp.json()["id"]

Los endpoints de conversión de ID cubren el conjunto completo: usuario a ID, ID a usuario actual, y URL de perfil a ID. Guarda los IDs; resuelve de vuelta a usuarios solo cuando los necesites para mostrar.

Paraleliza entre cuentas, no dentro de una

El cursor de paginación es secuencial por diseño: no puedes obtener la página 7 sin obtener primero las páginas 1 a la 6, ya que cada respuesta te entrega el cursor para la siguiente. No hay aceleración dentro de la extracción de una sola cuenta.

Entre cuentas es diferente. Para extraer seguidores de 20 competidores, corre esas 20 extracciones de forma concurrente contra el límite de 20 solicitudes/s. Con Python async:

python
import asyncio
import aiohttp

async def fetch_page(session, url, params):
    async with session.get(url, params=params, headers={"ApiKey": API_KEY}) as r:
        return await r.json()

async def extract_one(session, username):
    users = []
    cursor = None
    while True:
        params = {"username": username}
        if cursor:
            params["next_cursor"] = cursor
        data = await fetch_page(session, "https://api.sorsa.io/v3/followers", params)
        users.extend(data.get("users", []))
        cursor = data.get("next_cursor")
        if not cursor:
            return username, users
        await asyncio.sleep(0.05)

async def extract_many(usernames):
    async with aiohttp.ClientSession() as session:
        tasks = [extract_one(session, u) for u in usernames]
        return dict(await asyncio.gather(*tasks))

results = asyncio.run(extract_many(["stripe", "vercel", "supabase", "render"]))

Limita la concurrencia a tu límite de tasa dividido entre la latencia por solicitud. A 20 solicitudes/s y aproximadamente 150ms por solicitud, de tres a cuatro extracciones concurrentes saturan el techo.

Trabajar con los datos de respuesta

Cada objeto de usuario carga el perfil completo, así que la mayor parte del procesamiento posterior no necesita llamadas extra a la API. Algunas cosas que vale la pena saber sobre la forma:

  • El campo id es una cadena, no un entero, aunque se vea numérico. Los IDs de usuario de Twitter exceden el rango de entero con signo de 64 bits que algunos lenguajes manejan de forma nativa, así que la API los serializa como cadenas. No los conviertas a int a menos que tu herramienta maneje valores de 64 bits de forma segura.
  • El campo created_at es ISO 8601 (por ejemplo 2009-06-02T20:12:29Z), así que se parsea directamente: datetime.fromisoformat(created_at.replace("Z", "+00:00")). No se necesita una cadena de formato personalizada.
  • El description (bio) puede contener saltos de línea, emoji y unicode de todo tipo. Sanitízalo antes de escribir a CSV o cualquier pipeline que no maneje UTF-8 de forma limpia.
  • El campo location es una cadena de texto libre ingresada por el usuario, no un campo geográfico validado. Para datos de país confiables, el flujo de geografía de audiencia usa el endpoint /about para extraer la etiqueta de país que X adjunta a cada cuenta, y la guía para analizar seguidores por país recorre el desglose completo.

Para un análisis más profundo de la audiencia, nuestra comparación de métodos para extraer seguidores de Twitter recorre el filtrado por palabra clave de bio para la calificación de leads y encontrar cuentas que siguen a múltiples competidores. Para convertir una lista cruda en una hoja lista para CRM, revisa exportar datos de X a Google Sheets; para puntuar la misma lista en busca de cuentas falsas o inactivas, la guía de auditoría de seguidores falsos lo cubre. Este artículo se queda en la mecánica de la API.

Por qué /verified-followers existe como endpoint separado {#why-verified-followers-exists-as-a-separate-endpoint}

Filtrar los seguidores por verificación del lado del cliente es trivial (u.get("verified") is True), así que un endpoint dedicado /verified-followers se gana su lugar por dos razones prácticas. Primero, en cuentas con millones de seguidores donde los usuarios verificados son una pequeña minoría, recorrer toda la lista para sacarlos desperdicia solicitudes y tiempo de reloj; el endpoint devuelve solo el subconjunto verificado, ordenado de la misma forma que /followers. Segundo, el filtro de «audiencia de alto perfil» es lo bastante común en PR, periodismo, investigación de inversores y marketing de influencers como para valer una sola llamada.

bash
curl "https://api.sorsa.io/v3/verified-followers?username=stripe" \
  -H "ApiKey: YOUR_API_KEY"

La respuesta y el comportamiento de paginación son idénticos a /followers. Revisa la referencia de la API de seguidores verificados para el esquema completo.

Casos límite que te harán tropezar {#edge-cases-that-will-trip-you-up}

Incluso en una API limpia, los datos de seguidores tienen algunas rarezas que vale la pena conocer antes de que lances un pipeline. Las cuatro de abajo representan la mayoría de las sorpresas que los equipos encuentran en producción.

Las cuentas protegidas devuelven un error. Si el objetivo puso sus tweets como privados (la bandera protected es true), sus listas de seguidores y de seguidos no son accesibles para nadie fuera de sus seguidores aprobados, y el endpoint devuelve un error en lugar de un resultado parcial. Revisa la bandera protected del perfil con el endpoint /info antes de la extracción si estás programando a lo largo de muchas cuentas.

El conteo de seguidores y la lista extraíble no coincidirán exactamente. El followers_count de un perfil es un contador en tiempo real que X mantiene. La lista que recorres a través de la API puede regresar ligeramente más pequeña por cuentas suspendidas, usuarios desactivados, y cuentas que recientemente dejaron de seguir pero aún no se han vaciado del contador. Espera un pequeño porcentaje de deriva en cuentas grandes, y no escribas revisiones de igualdad estricta contra followers_count.

Los datos de perfil son actuales, no históricos. Cada objeto de usuario refleja el perfil como existe ahora, no su estado cuando ocurrió el follow. Si alguien siguió a Stripe en 2019 y desde entonces se renombró, el username en tu extracción es el nuevo usuario. El id numérico es estable; el usuario no.

El orden es aproximadamente cronológico inverso. Tanto /followers como /follows devuelven los resultados en el orden que X provee, generalmente los follows más nuevos primero, así que las primeras páginas contienen los seguidores adquiridos más recientemente. X no se ha comprometido oficialmente con este orden, así que no construyas lógica que dependa de que se mantenga fijo para siempre, aunque se ha mantenido consistente en la práctica.

Cuándo la API oficial de X todavía tiene sentido {#when-the-official-x-api-still-makes-sense}

La API oficial de X es la elección correcta en dos casos específicos: leer los datos de tu propia cuenta, y cualquier flujo de trabajo que tenga que escribir. Leer tus propios seguidores se volvió barato el 20 de abril de 2026 a la tarifa de lectura propia de $0.001, así que para dashboards personales y herramientas de gestión de cuenta el GET /2/users/:id/followers oficial con autenticación de contexto de usuario OAuth es un ajuste razonable. Las acciones de escritura (publicar, dar like, seguir) son exclusivas de la API oficial y no algo que los proveedores enfocados en lectura manejen.

Para cualquier cuenta de terceros, que es el caso realista para casi toda aplicación comercial, el cálculo cambia. El costo por recurso sube aproximadamente diez veces comparado con las lecturas propias, OAuth 2.0 agrega fricción al flujo de autenticación, y los límites de tasa se hacen cumplir en ventanas de 15 minutos que devuelven un 429 cuando se superan y que pagar más no levanta. Para los equipos que se mueven fuera de la API oficial tras los cambios de precio, la documentación de migración de Sorsa cubre el mapeo endpoint por endpoint.

El árbol de decisión es corto:

  1. ¿Solo lees los datos de tu propia cuenta? La API oficial de X está bien. Barata, y los datos son canónicos.
  2. ¿Lees los datos de cualquier otra cuenta? Una API alternativa de Twitter/X es el mejor ajuste. La brecha de costo es lo bastante grande como para no necesitar un análisis más cercano.
  3. ¿Necesitas publicar, dar like, o seguir? Solo la API oficial de X. Las acciones de escritura están fuera del alcance de un proveedor de solo lectura como Sorsa.

En la práctica

Reconstruimos un trabajo de extracción de seguidores para un fondo cuantitativo que rastreaba el sentimiento a lo largo de cuentas fintech de X. Necesitaban las listas de seguidores de unas 50 cuentas competidoras de nivel medio, con un promedio de 80,000 seguidores cada una, aproximadamente cuatro millones de objetos de usuario en total. A la tarifa de lectura no propia de la API oficial, esa extracción de una sola vez salía cerca de $40,000. El mismo trabajo en una API de terceros de tarifa plana salió en unos $40 de cuota y corrió en una tarde, con una forma de datos idéntica. El motor es estructural en lugar de un descuento: la API oficial cobra cada objeto de usuario que devuelve, mientras que una API por solicitud cobra la llamada y devuelve 200 perfiles dentro de ella. Para audiencias en los millones, muestrear los primeros 10,000 a 20,000 seguidores (50 a 100 solicitudes) suele ser representativo de la audiencia reciente y evita pagar por recorrer toda la cola.

Preguntas frecuentes {#faq}

¿Qué es la API de seguidores de Twitter?

La API de seguidores de Twitter es el conjunto de endpoints que recuperan de forma programática las cuentas que siguen a un usuario de Twitter/X, y en la misma familia de endpoints, las cuentas que ese usuario sigue. La versión oficial es GET /2/users/:id/followers y GET /2/users/:id/following. Los proveedores de terceros como Sorsa exponen los mismos datos a través de una sola clave API y cobro por solicitud en lugar de OAuth y cobro por recurso.

¿Cómo obtienes una lista de seguidos de Twitter por API?

Para obtener una lista de seguidos (las cuentas que un usuario sigue, no las cuentas que lo siguen), llama al endpoint «following» en lugar del de seguidores. En la API oficial ese es GET /2/users/:id/following; en Sorsa es GET /v3/follows, con los mismos parámetros y paginación de 200 por página que el endpoint de seguidores. Las listas de seguidos suelen ser más pequeñas que las listas de seguidores y a menudo más reveladoras, ya que muestran a quién elige seguir una cuenta.

¿Cuánto cuesta la API oficial de X para datos de seguidores en 2026?

Después de la actualización del 20 de abril de 2026, X cobra $0.001 por recurso por las «Owned Reads» (tus propios datos) y la tarifa estándar de lectura no propia, $0.010 por recurso, para los datos de cualquier otra cuenta. La factura se calcula por objeto de usuario devuelto, no por solicitud. Una lista de seguidores de 100,000 cuentas en una lectura no propia son unos $1,000.

¿Cuál es la diferencia entre el cobro por recurso y el cobro por solicitud?

El cobro por recurso cuenta cada objeto de usuario en una respuesta como un cargo separado, así que una solicitud de la API oficial que devuelve 1,000 seguidores cuesta lo mismo que 1,000 consultas individuales. El cobro por solicitud, que usa Sorsa, cuenta toda la solicitud como una unidad contra tu cuota mensual sin importar cuántos usuarios regresen. Para las listas de seguidores, donde cada llamada devuelve hasta 200 usuarios, esa es la diferencia entre pagar por 200 cosas o por una.

¿Deberías usar user_id o username en las llamadas a la API?

Usa username para consultas ad-hoc y exploración. Usa user_id para cualquier código que corra más de una vez. Los usuarios cambian cuando las cuentas se renombran; el ID numérico es estable durante toda la vida de la cuenta. Para trabajos programados, resuelve el username a un user_id una vez con el endpoint username-to-id, guárdalo y pasa user_id de ahí en adelante.

¿Cómo manejas la respuesta 429 de límite de tasa?

Duerme un segundo y reintenta. El límite de 20 solicitudes/s de Sorsa no tiene penalización por chocarlo: obtienes un 429, esperas, y la siguiente solicitud funciona. No hay token buckets, ni ventanas de 15 minutos, ni sublímites por endpoint. Un envoltorio de reintento ligero que atrapa las respuestas 429 y 5xx con un backoff corto es suficiente para producción.

¿Por qué el conteo extraído no coincide con el followers_count del perfil?

El valor followers_count es un contador en tiempo real que X mantiene, así que la lista extraíble puede regresar ligeramente más pequeña. Las cuentas suspendidas, los usuarios desactivados y la gente que recientemente dejó de seguir pero no se ha vaciado del contador crean deriva. Espera un pequeño porcentaje de diferencia en cuentas grandes. Este es comportamiento de la plataforma, no un bug en tu código, así que evita las revisiones de igualdad estricta.

¿Qué tan frescos son los datos de seguidores?

Los objetos de usuario reflejan el perfil como existe en el momento de la solicitud, así que los conteos, las bios, las imágenes de perfil y el estado de verificación están vigentes. Las relaciones de follow típicamente se reflejan en cuestión de segundos a minutos de ocurrir en X. Para algo más cercano al streaming, los patrones de monitoreo en tiempo real cubren cómo detectar nuevos seguidores y menciones en un intervalo estrecho.

Cómo empezar {#getting-started}

Para probar esto contra tu propia cuenta o cualquier cuenta pública:

  1. Regístrate para una clave API en el dashboard de overview. Cada clave nueva incluye 100 solicitudes gratis: por única vez, sin tarjeta requerida, sin expiración y válidas en los 40 endpoints. En los endpoints de seguidores eso son hasta 20,000 perfiles antes de que pagues nada.
  2. Corre el ejemplo de cURL o Python de arriba con tu usuario como el parámetro username.
  3. Para una vista previa sin código, abre el API Playground y llama a /followers directamente en el navegador.
  4. Los datos de seguidores en Sorsa cuestan desde $0.01 por cada 1,000 perfiles, ya que una solicitud devuelve hasta 200 perfiles completos a una tarifa plana por solicitud. Planea para volumen en la página de precios: desde $0.02 por cada 1,000 perfiles en Starter y desde $0.01 por cada 1,000 perfiles en Pro y Enterprise, con cada plan corriendo a las 20 solicitudes por segundo.

El código completo, la referencia de endpoints y los patrones de paginación viven en la documentación de seguidores y seguidos. Para extracción sin API (extensiones de navegador, scrapers caseros, exportaciones manuales de datos de X), revisa la comparación de métodos enlazada en la parte superior de esta guía. Para ver cómo se compara el mercado de API de datos de Twitter de terceros con la API oficial de X en general en 2026, revisa nuestro desglose de alternativas a la API de Twitter.

Revisado por Keksich, fundador de Sorsa, marketer e investigador de la API de X.

Cómo se armó esta guía: los endpoints, el código y los patrones vienen de nuestro propio trabajo construyendo y operando la API de Twitter/X de Sorsa y corriendo la extracción de seguidores contra cuentas públicas en vivo. Los costos y el modelo de la API oficial se verificaron contra el precio de desarrolladores publicado de X y el comportamiento de límite de tasa documentado en los recursos de desarrolladores de X. Última verificación en julio de 2026.