Convertidor de ID de Twitter: usuario, user ID y enlace de perfil

Por Sorsa Editorial

Actualizado en julio de 2026: agregada la opción inicial de 100 solicitudes gratis (sin tarjeta requerida), reformulado el precio de conversión a tarifas planas por cada 1,000 conversiones, y re-verificadas las tarifas de lectura de pago por uso oficiales.

Conclusión clave: Un ID de usuario de Twitter (X) es un número permanente de 64 bits asignado en la creación de la cuenta, mientras que el @username puede cambiar en cualquier momento. Para convertir entre ellos, envía el usuario, el ID numérico o la URL de perfil a un endpoint de consulta. Guarda el ID, no el usuario, ya que el ID sobrevive a los renombres.

Si alguna vez has guardado @brand_name como clave primaria y luego viste esa cuenta cambiar su marca a @new_brand, ya sabes por qué esto importa. X deja que los usuarios cambien un usuario cuando quieran, y una vez que @brand_name se libera, cualquiera puede reclamarlo. El ID numérico de usuario es el único identificador que permanece adjunto a la cuenta original de por vida.

Para hacer estas conversiones en código, Sorsa API, un proveedor alternativo de API de Twitter/X, expone tres endpoints dedicados (usuario a ID, ID a usuario, URL de perfil a ID) detrás de una sola clave API, sin flujo OAuth y sin cola de aprobación de app. Cada conversión cuenta como una sola solicitud en lugar del conteo por recurso que usa la API oficial, así que resolver 100,000 usuarios sale desde $199 en el plan Pro contra aproximadamente $1,000 en créditos de la API oficial de X. Cada clave nueva empieza con 100 solicitudes gratis (por única vez, sin tarjeta requerida, sin expiración, los 40 endpoints), suficientes para convertir un primer lote de cuentas antes de decidirte por un plan. Para consultas puntuales donde no quieres escribir código, el playground gratuito del ID Converter hace las tres conversiones en el navegador sin ninguna clave.

Divulgación: Sorsa API es nuestro producto. Las comparaciones de precio de abajo usan las tarifas de pago por uso publicadas de la API oficial de X, verificadas en julio de 2026. Revisa las tarifas vigentes contra tu propia carga de trabajo antes de comprometerte.

Esta guía es el camino del desarrollador a través del tema: cuándo realmente necesitas convertir, por qué importa el diseño de estos identificadores, cómo hacer cada conversión en código y cómo correrla a lo largo de miles de cuentas sin que tu pipeline se rompa.

Tabla de contenidos

• Por qué los user IDs son el único identificador en el que puedes confiar
• Cómo se generan los user IDs de Twitter
• Cómo encontrar un user ID de Twitter
• Las tres operaciones de conversión
• ¿Cuánto cuesta la conversión de ID en 2026?
• Convertir con la Sorsa API
• Conversión por lotes a escala
• Normalizar entradas mixtas
• Detectar cambios de usuario
• En la práctica
• Cómo empezar
• Preguntas frecuentes

Por qué los user IDs son el único identificador en el que puedes confiar {#why-user-ids-are-the-only-identifier-you-can-trust}

Un username en X es mutable. Un usuario puede cambiar @old_name a @new_name hoy, y mañana alguien más puede agarrar @old_name. Si una aplicación trata el usuario como clave primaria, dos cosas se rompen a la vez: cada referencia guardada apunta a la cuenta equivocada, y un tercero puede ahora tener el usuario que solías asociar con el usuario original.

Este no es un caso límite raro. Un estudio longitudinal que monitoreó 8.7 millones de cuentas encontró que alrededor del 10% de los usuarios de Twitter cambian su usuario con el tiempo (Jain y Kumaraguru, IIIT-Delhi). En nuestro propio trabajo ayudando a empresas a moverse fuera de la API oficial de X tras la revisión de precios de 2023, la rotación de usuarios fue uno de los problemas de corrupción de datos silenciosa más comunes que encontramos. Varios clientes corrían dashboards de monitoreo que guardaban usuarios como claves foráneas, y cuando un competidor rastreado cambió su marca, el dashboard siguió felizmente recolectando tweets de una cuenta completamente ajena que había tomado el usuario viejo.

El ID de usuario es un entero de 64 bits asignado en la creación de la cuenta. No se puede cambiar, no se puede transferir, es único en toda la plataforma y es la clave de unión sobre la que se construye todo pipeline de datos de X confiable:

• Los cambios de usuario no rompen tu sistema. Ya sea que una cuenta se renombre una vez o cincuenta veces, el ID apunta al mismo perfil.
• Los índices son más rápidos. La indexación por entero es más eficiente en almacenamiento que las cadenas de longitud variable, y las consultas por clave primaria numérica le ganan a las consultas por username a cualquier escala.
• Las uniones entre tiempos se mantienen limpias. Al emparejar cuentas a través de datasets recolectados en momentos diferentes, los IDs son la única clave segura. Una coincidencia de usuario a lo largo de años puede emparejar silenciosamente a dos personas distintas.
• Varios endpoints requieren IDs. El /info-batch de Sorsa acepta user_ids, los endpoints de listas y de comunidades referencian cuentas por ID numérico, y la mayoría de los endpoints de la API oficial de X igualmente esperan IDs numéricos.

Si te llevas una cosa de este artículo: guarda IDs en tu base de datos, no usuarios. Trata el usuario como datos de visualización en caché que pueden quedar obsoletos.

Guarda el ID como cadena, no como entero

Guarda y transporta los user IDs de Twitter como cadenas, aunque se vean como números. Los IDs Snowflake modernos de 19 dígitos exceden el límite de entero seguro de JavaScript (Number.MAX_SAFE_INTEGER, que es 2^53 - 1, o 9,007,199,254,740,991), así que parsear un ID a un número JS nativo redondea silenciosamente los últimos dígitos y lo corrompe. El mismo riesgo aparece en cualquier lugar donde un valor de 64 bits aterrice en un tipo de 32 bits o de punto flotante. Mantén los IDs en columnas de cadena o en un BIGINT de 64 bits, nunca en un int por defecto ni en un number de JavaScript. La Sorsa API devuelve cada ID como una cadena JSON exactamente por esta razón.

Cómo se generan los user IDs de Twitter {#how-twitter-user-ids-are-generated}

Twitter construyó su sistema de generación de IDs, Snowflake, en 2010 para resolver un problema de sistemas distribuidos. A la escala de Twitter, preguntarle a una base de datos central «¿cuál es el siguiente ID?» por cada nuevo tweet, mensaje o cuenta no funcionaría. Snowflake deja que cualquier servidor acuñe enteros de 64 bits únicos a nivel global de forma independiente, sin coordinación, combinando tres valores:

• Marca de tiempo (41 bits): milisegundos desde la época de Twitter (2010-11-04 01:42:54.657 UTC).
• ID de worker / máquina (10 bits): identifica el servidor que generó el ID.
• Número de secuencia (12 bits): se incrementa dentro del mismo milisegundo, permitiendo hasta 4,096 IDs por máquina por milisegundo.

Suma un bit de signo y tienes 64 bits en total. Como la marca de tiempo se sitúa en los bits más significativos, los IDs Snowflake son aproximadamente ordenables por tiempo, y por eso los IDs de tweets están ordenados por tiempo cuando los comparas.

El detalle del user ID que la mayoría de las páginas de convertidores se equivocan

Aquí hay un punto que la mayoría de las páginas de convertidores de ID afirman incorrectamente: los IDs de tweets pasaron a Snowflake en 2010, pero X no cambió los user IDs al formato Snowflake hasta febrero de 2016, y muchas páginas todavía repiten una fecha equivocada (a menudo 2020). Según el propio anuncio de migración a IDs de 64 bits de X, los IDs Snowflake empezaron a desplegarse a usuarios, listas y búsquedas guardadas el 1 de febrero de 2016. Antes de eso, X repartió IDs de usuario enteros cortos y secuenciales por años. Es por eso que la cuenta de Jack Dorsey es 12, y por qué las cuentas creadas antes del cambio tienen IDs cortos y bajos mientras que las cuentas creadas después tienen IDs Snowflake largos, de 18 a 19 dígitos.

La consecuencia práctica: puedes extraer una marca de tiempo de creación de cualquier ID de tweet, pero no puedes extraer de forma confiable una fecha de registro de un user ID viejo, porque los user IDs previos a 2016 no cargan ninguna marca de tiempo embebida. Si necesitas una fecha de alta para una cuenta más vieja, lee el campo created_at del perfil directamente, o usa el verificador de antigüedad de cuenta para una consulta puntual rápida.

Cómo encontrar un user ID de Twitter {#how-to-find-a-twitter-user-id}

X no muestra un user ID en ninguna parte de su interfaz, así que tienes que derivarlo. Hay tres caminos prácticos, en orden aproximado de esfuerzo:

La forma manual (lenta). Abre el perfil, ve el código fuente de la página (Ctrl+U o Cmd+U) y busca en el HTML user_id o rest_id. O abre las herramientas de desarrollador del navegador (F12), observa la pestaña Network, refresca y lee el ID de una respuesta de API. Ambos funcionan para una sola cuenta, pero son tediosos, se rompen cada vez que X reorganiza su marcado y no escalan más allá de un puñado de consultas.

Un convertidor gratuito (puntual). Pega un usuario, un ID, o una URL de perfil en una herramienta de consulta y lee el resultado. El playground del Sorsa ID Converter maneja las tres direcciones en el navegador sin registro y sin clave API, y también devuelve el perfil para que puedas confirmar que tienes la cuenta correcta. Las cuentas suspendidas, borradas o que nunca existieron devuelven un resultado de no encontrado; las cuentas protegidas (privadas) devuelven el ID pero estadísticas limitadas.

La API (a escala). Cuando necesitas resolver más de unas pocas cuentas, o correr la consulta sin supervisión dentro de un pipeline, llama a un endpoint de conversión directamente. El código de abajo muestra las tres operaciones en Python.

Las tres operaciones de conversión {#the-three-conversion-operations}

Hay exactamente tres operaciones de conversión que alguna vez necesitas:

Cada operación es una sola llamada a la API. Ninguna de ellas requiere OAuth, URLs de callback o aprobación de app cuando usas una API de terceros como Sorsa. Una clave de terceros reemplaza el flujo de cuenta de desarrollador oficial por completo, así que no hay solicitud que enviar ni nada que esperar, el mismo camino cubierto en nuestra guía sobre usar la API de X sin una cuenta de desarrollador. Los ejemplos de Python y curl para las tres están en la sección de código de abajo, y cada una mapea a un endpoint documentado: usuario a ID, ID a usuario, y enlace de perfil a ID.

No hay una operación equivalente para los tweets. Un ID de tweet es visible directamente en la URL del tweet (x.com/user/status/1234567890), así que lo parseas de la cadena de la URL en lugar de llamar a una consulta.

Cuándo usar el endpoint /info en su lugar

Si necesitas tanto el user ID como el perfil completo (nombre para mostrar, conteo de seguidores, bio, URL de avatar), no llames a /username-to-id y luego a /info por separado. Llama a /info?username=... directamente: devuelve el perfil completo, incluido el campo id, en una sola solicitud. Dividirlo en dos llamadas es uno de los errores de costo más comunes que vemos en las revisiones de código. A volúmenes más grandes, /info-batch empaqueta hasta 100 perfiles en una solicitud, lo que lleva el costo de extraer IDs junto con perfiles completos a desde $0.01 por cada 1,000 perfiles en los planes con precio por lote.

¿Cuánto cuesta la conversión de ID en 2026? {#how-much-does-id-conversion-cost-in-2026}

El precio cambió significativamente este año. En febrero de 2026 X movió su API a un modelo de créditos de pago por uso como opción por defecto para los desarrolladores nuevos, reemplazando los antiguos niveles Basic y Pro. Una consulta de usuario a ID en la API oficial de X es una lectura de usuario, cobrada a aproximadamente $0.010 por recurso devuelto, que sale en aproximadamente $10.00 por cada 1,000 conversiones. Para una consulta ocasional dentro de una herramienta interna, eso está bien. Para trabajos por lotes o recurrentes el costo suma rápido: resolver 100,000 usuarios cuesta aproximadamente $1,000 en créditos de la API oficial.

En Sorsa, cada uno de los tres endpoints de conversión cuenta como una sola solicitud, así que el costo aterriza desde $1.80 por cada 1,000 conversiones, y cada clave nueva empieza con 100 solicitudes gratis (por única vez, sin tarjeta requerida, sin expiración, los 40 endpoints) para probar el flujo primero:

Por conversión, el plan Pro sale en aproximadamente 5 veces más barato que la API oficial, y la brecha se ensancha si haces lotes: las consultas de perfil a través de /info-batch empaquetan hasta 100 cuentas en una sola solicitud. Para el panorama completo de cómo cambió el modelo oficial este año, revisa nuestro desglose de precios de la API de Twitter y las razones detrás de por qué la API oficial es tan cara. Los detalles de los planes de nuestro lado están en la página de precios.

Una salvedad honesta del lado oficial: su nivel de lectura más barato, las lecturas propias a $0.001 por recurso, es genuinamente competitivo, pero solo aplica cuando una app lee los datos de su propia cuenta a través de un conjunto fijo de endpoints. Las consultas de usuario a ID para cuentas de terceros arbitrarias son lecturas no propias cobradas a la tarifa estándar de lectura de usuario, así que el modelo de tarifa plana por solicitud se mantiene adelante para el trabajo de conversión que cubre esta guía.

Convertir con la Sorsa API {#converting-with-the-sorsa-api}

La autenticación es un solo encabezado: ApiKey: YOUR_API_KEY. Sin flujo OAuth, sin scopes, sin callback. Cada una de las tres operaciones mapea a un endpoint documentado, y comparten la misma clave.

import requests

API_KEY = "YOUR_API_KEY"
BASE = "https://api.sorsa.io/v3"
HEADERS = {"ApiKey": API_KEY}


def username_to_id(handle: str) -> str:
    """Resolve a handle (without @) to its permanent numeric user ID."""
    resp = requests.get(f"{BASE}/username-to-id/{handle}", headers=HEADERS)
    resp.raise_for_status()
    return resp.json()["id"]  # returned as a string, keep it that way


def id_to_username(user_id: str) -> str:
    """Resolve a numeric user ID to the account's current handle."""
    resp = requests.get(f"{BASE}/id-to-username/{user_id}", headers=HEADERS)
    resp.raise_for_status()
    return resp.json()["handle"]


def link_to_id(profile_url: str) -> str:
    """Extract the numeric user ID from a full profile URL."""
    resp = requests.get(
        f"{BASE}/link-to-id",
        headers=HEADERS,
        params={"link": profile_url},
    )
    resp.raise_for_status()
    return resp.json()["id"]


# Examples
print(username_to_id("elonmusk"))                    # "44196397"
print(id_to_username("44196397"))                    # "elonmusk"
print(link_to_id("https://x.com/elonmusk"))          # "44196397"

Para un equivalente en curl de la primera llamada:

curl "https://api.sorsa.io/v3/username-to-id/elonmusk" \
  -H "ApiKey: YOUR_API_KEY"
# {"id": "44196397"}

Conversión por lotes a escala {#batch-conversion-at-scale}

Cuando tienes una hoja de cálculo de usuarios de competidores, una exportación de CRM o una lista de cuentas para sembrar un pipeline de monitoreo, necesitas convertirlas todas a IDs en una sola pasada. El patrón de abajo agrega lógica de reintento, límite de tasa suave (Sorsa permite 20 solicitudes por segundo por clave en todos los planes) y manejo elegante de cuentas suspendidas o borradas. Para una cobertura más amplia de paginación, lotes y manejo de errores a lo largo del resto de la API en Python, revisa la guía de la API de Twitter en Python.

import requests
import time
from typing import Iterable

API_KEY = "YOUR_API_KEY"
BASE = "https://api.sorsa.io/v3"
HEADERS = {"ApiKey": API_KEY}


def batch_username_to_id(handles: Iterable[str], pause: float = 0.05) -> dict[str, str | None]:
    """
    Resolve a list of handles to user IDs.

    Returns a dict mapping handle -> id (or None if the lookup failed).
    Soft rate limit: ~20 req/s, well under Sorsa's per-key cap.
    """
    results: dict[str, str | None] = {}

    for handle in handles:
        handle = handle.strip().lstrip("@")
        try:
            resp = requests.get(f"{BASE}/username-to-id/{handle}", headers=HEADERS, timeout=10)
            if resp.status_code == 200:
                results[handle] = resp.json()["id"]
            elif resp.status_code == 404:
                results[handle] = None  # Account does not exist or is suspended
            elif resp.status_code == 429:
                time.sleep(1)  # Back off and retry once
                retry = requests.get(f"{BASE}/username-to-id/{handle}", headers=HEADERS, timeout=10)
                results[handle] = retry.json()["id"] if retry.status_code == 200 else None
            else:
                results[handle] = None
        except requests.RequestException:
            results[handle] = None

        time.sleep(pause)

    return results


handles = ["NASA", "SpaceX", "Tesla", "OpenAI", "stripe"]
id_map = batch_username_to_id(handles)

for handle, uid in id_map.items():
    print(f"@{handle:<10} -> {uid or '(not found)'}")

La dirección inversa funciona de la misma forma. Cambia la URL por /id-to-username/{user_id} y lee el campo handle de la respuesta.

Normalizar entradas mixtas {#normalizing-mixed-input}

Una situación común: tu aplicación acepta referencias de cuenta de usuarios finales o de sistemas upstream en el formato que la fuente resulte producir. Algunas entradas son usuarios pelones, algunas llevan el prefijo @, algunas son URLs completas, algunas ya son IDs numéricos. El normalizador de abajo colapsa las cuatro formas en un user ID estable, y se salta la llamada a la API por completo cuando la entrada ya es un ID.

def normalize_to_id(value: str) -> str:
    """
    Accept any of:
      - "elonmusk"
      - "@elonmusk"
      - "https://x.com/elonmusk"
      - "https://twitter.com/elonmusk"
      - "44196397"
    Returns the numeric user ID as a string.
    """
    value = value.strip().lstrip("@")

    # Already a numeric ID, no API call needed
    if value.isdigit():
        return value

    # Profile URL
    if "x.com/" in value or "twitter.com/" in value:
        return link_to_id(value)

    # Bare username
    return username_to_id(value)


# All four return the same ID
for source in ["elonmusk", "@elonmusk", "https://x.com/elonmusk", "44196397"]:
    print(f"{source:<35} -> {normalize_to_id(source)}")

Usa esto como el primer paso en cualquier pipeline de ingesta. Garantiza que la lógica posterior siempre trabaje con el identificador estable, sin importar qué tan desordenada sea la entrada.

Detectar cambios de usuario {#detecting-handle-changes}

Si guardaste tanto el user ID como el usuario al momento de la recolección, puedes re-resolver los IDs periódicamente y detectar qué cuentas se han renombrado. Este es el flujo para refrescar una base de datos que puede tener nombres para mostrar obsoletos.

def detect_renames(records: list[dict]) -> list[dict]:
    """
    records: list of {"user_id": str, "stored_handle": str}
    Returns: list of {"user_id", "old_handle", "new_handle"} for renamed accounts.
    """
    changes = []
    for record in records:
        try:
            current = id_to_username(record["user_id"])
        except requests.HTTPError:
            continue  # Account deleted, suspended, or transient error

        if current and current.lower() != record["stored_handle"].lower():
            changes.append({
                "user_id": record["user_id"],
                "old_handle": record["stored_handle"],
                "new_handle": current,
            })
        time.sleep(0.05)

    return changes


db_records = [
    {"user_id": "44196397", "stored_handle": "elonmusk"},
    {"user_id": "1234567890", "stored_handle": "old_brand_name"},
]

for change in detect_renames(db_records):
    print(f"Renamed: @{change['old_handle']} -> @{change['new_handle']} (ID {change['user_id']})")

Para una auditoría de renombres más rica, el endpoint /about devuelve username_change_count y last_username_change_at. Eso te dice no solo el usuario actual sino cuántas veces una cuenta se ha renombrado y cuándo ocurrió el cambio más reciente.

En la práctica {#in-practice}

Un equipo de analítica social de unas 12 personas llegó a nosotros después de que un competidor que rastreaban cambió su marca, y su dashboard ingirió calladamente los tweets de un extraño por casi tres semanas antes de que alguien lo notara. La causa raíz era la clásica: habían guardado usuarios como claves. El arreglo fue estructural en lugar de ingenioso. Resuelve cada usuario a su user ID en la ingesta, guarda el ID como la clave, mantén el usuario como solo-visualización y corre un re-resolve programado para atrapar los renombres (el patrón detect_renames de arriba).

El lado del costo también importó. Su volumen mensual de resolución de usuarios había estado rondando los $1,000 en créditos de lectura de usuario de la API oficial de X. En el plan Pro a $199 fijos por 100,000 solicitudes se volvió una partida predecible, aproximadamente una reducción de 5x en esa carga de trabajo, con margen extra porque las consultas de perfil masivas a través de /info-batch empacan hasta 100 cuentas en una solicitud. La victoria de confiabilidad, sin más corrupción silenciosa entre cuentas, fue la parte que más les importó.

Cómo empezar {#getting-started}

Tres formas de probar esto:

1. Sin código, sin registro. Abre el playground del ID Converter y pega cualquier usuario, ID, o URL de perfil. Útil para consultas puntuales y para confirmar que una cuenta existe antes de escribir código.
2. Clave API con 100 solicitudes gratis. Crea una cuenta gratis y cada clave empieza con 100 solicitudes gratis (por única vez, sin tarjeta requerida, sin expiración, los 40 endpoints). Pon la clave en el encabezado ApiKey y los ejemplos de Python de arriba corren tal cual. Los planes de pago empiezan desde $0.0049 por conversión en Starter, bajando a $0.00199 en Pro, y las 20 solicitudes por segundo aplican en todos los planes.
3. ¿Ya estás en la API oficial de X? La guía de migración mapea cada endpoint oficial a su equivalente de Sorsa, y nuestra visión general de alternativas a la API de Twitter cubre los trade-offs.

Los tres endpoints de conversión aquí son parte de una API de solo lectura de 40 endpoints que cubre perfiles, tweets, seguidores, búsqueda y verificación.

Preguntas frecuentes {#frequently-asked-questions}

¿Qué es un ID de usuario de Twitter (X)?

Un ID de usuario de Twitter es un entero único de 64 bits asignado a una cuenta de X cuando se crea. Es permanente: no se puede cambiar, transferir, ni reasignar. A diferencia del username (usuario), que se puede editar en cualquier momento, el ID de usuario permanece adjunto a la misma cuenta durante toda la vida de esa cuenta, y por eso los desarrolladores lo usan como la clave estable para cualquier referencia de cuenta.

¿Cómo encuentras tu propio ID de usuario de Twitter?

La interfaz de X no muestra tu ID de usuario en ninguna parte. Para encontrarlo, pega tu usuario o URL de perfil en un convertidor como el Sorsa ID Converter, o envía tu usuario a un endpoint de consulta. También puedes descargar tu archivo de datos de X desde la configuración de la cuenta, que incluye tu ID de usuario en los metadatos de la cuenta.

¿Puede cambiar un ID de usuario de Twitter?

No. Un ID de usuario de Twitter se asigna en la creación de la cuenta y es permanente durante la vida de la cuenta. Renombrar la cuenta, cambiar el nombre para mostrar, cambiar de correo o ser suspendido y luego reinstalado no cambia el ID de usuario. Lo único que cambia es el vínculo entre un usuario y un ID, que se mueve cuando el usuario mismo se cambia y el usuario viejo queda disponible para que alguien más lo reclame.

¿Por qué algunos IDs de usuario de Twitter son cortos y otros muy largos?

X asignó IDs enteros cortos y secuenciales a las cuentas tempranas, y por eso la cuenta de Jack Dorsey es 12, y solo cambió los IDs de usuario al formato Snowflake de 64 bits en febrero de 2016. Las cuentas creadas antes de ese cambio tienen IDs cortos y bajos. Las cuentas creadas después tienen IDs Snowflake largos, de alrededor de 18 a 19 dígitos, que codifican una marca de tiempo de creación en los bits superiores.

¿Se puede decodificar una fecha de registro a partir de un ID de usuario?

Para las cuentas creadas después del cambio a Snowflake en febrero de 2016, sí: desplaza el ID 22 bits a la derecha, suma la época de Twitter (1288834974657) y obtienes la marca de tiempo de creación en milisegundos. Para las cuentas más viejas con IDs secuenciales previos a 2016, no, porque esos IDs no cargan ninguna marca de tiempo embebida. En ese caso extrae el perfil y lee el campo created_at directamente.

¿Hay un convertidor de ID de Twitter gratuito que no requiera una clave API?

Sí. El playground del Sorsa ID Converter maneja las tres operaciones (usuario a ID, ID a usuario, URL de perfil a ID) en el navegador sin clave API y sin registro, y devuelve el perfil para que puedas confirmar la cuenta. Está hecho para consultas puntuales. Para trabajos por lotes, pipelines recurrentes o cualquier cosa que corra sin supervisión, una clave API es el mejor ajuste, y cada clave nueva empieza con 100 solicitudes gratis (por única vez, sin tarjeta requerida) para que puedas probar un lote antes de pagar.

¿Cómo pueden los desarrolladores convertir miles de usuarios a IDs a escala?

Para trabajo de alto volumen, la Sorsa API expone tres endpoints de conversión (/username-to-id, /id-to-username, /link-to-id) a una tarifa plana de una solicitud por conversión. En el plan Pro a $199/mes por 100,000 solicitudes, cada conversión es de aproximadamente $0.002, unas 5 veces más barato que la tarifa por recurso de la API oficial. El rendimiento tiene un tope de 20 solicitudes por segundo por clave, lo bastante alto como para que tu propio código sea usualmente el cuello de botella, no la API.

¿Cuál es la diferencia entre un ID de usuario y un ID de tweet?

Ambos son enteros estilo Snowflake de 64 bits, pero viven en espacios de nombres separados e identifican cosas diferentes. Un ID de usuario identifica una cuenta; un ID de tweet (también llamado ID de estado) identifica una sola publicación. Los IDs de tweet son visibles directamente en la URL del tweet (x.com/user/status/{tweet_id}), así que no se necesita ninguna consulta para ellos. Los IDs de usuario no están expuestos en ninguna parte de la interfaz de X, y por eso existen endpoints de conversión dedicados.

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

Cómo se armó esta guía: se apoya en nuestro trabajo práctico construyendo y operando una API alternativa de Twitter/X y en pruebas directas contra nuestros endpoints de conversión en vivo, contrastadas con la documentación de Sorsa API para el comportamiento de los endpoints y el anuncio de precios de la API de X oficial para las tarifas de pago por uso vigentes. La estructura de Snowflake proviene de la publicación de ingeniería original de Twitter, el cambio de user ID de febrero de 2016 del anuncio de migración a IDs de 64 bits de X y la cifra de rotación de usuarios del estudio longitudinal de Jain y Kumaraguru. Cifras de precio y de tasa verificadas en julio de 2026. Más sobre quiénes somos está en nuestra página about.