Skip to main content
Reduce solicitudes innecesarias reutilizando perfiles incluidos en las respuestas, agrupando consultas y guardando resultados por ID estable. Estos ejemplos muestran cuándo aplicar cada enfoque.
Consejo: las 100 solicitudes gratuitas, sin tarjeta ni caducidad, permiten probar estos patrones y medir el consumo real antes de elegir un plan.

Configuración de los ejemplos

Los ejemplos de Python utilizan requests (python -m pip install requests) y se ejecutan en tu backend. Sustituye la clave y los IDs de ejemplo. search_results representa una lista de publicaciones de una solicitud anterior.

Principio 1: Las publicaciones ya incluyen datos del usuario

Todos los endpoints de publicaciones, como /search-tweets, /user-tweets, /list-tweets, /comments, /quotes y /mentions, incluyen el perfil completo del autor dentro de cada objeto.
user contiene los mismos datos que una consulta a /info: ID, nombres, biografía, seguidores, cuentas seguidas, publicaciones, verificación, ubicación, creación, imagen y más. Aplicación práctica: si buscas publicaciones sobre un tema para crear una lista de autores, no necesitas llamar a /info por cada uno. Extrae los datos de la respuesta:
Este patrón puede evitar cientos o miles de solicitudes innecesarias.

Principio 2: Utiliza endpoints por lotes

Las variantes por lotes de las consultas habituales reducen considerablemente las llamadas.

/info-batch en lugar de repetir /info

Obtén hasta 100 perfiles a la vez:
Ahorro: 10 cuentas requieren 1 solicitud en lugar de 10. La reducción aumenta hasta 100 cuentas por llamada.

/tweet-info-bulk en lugar de repetir /tweet-info

Si tienes IDs procedentes de un archivo, exportación o marcadores, consulta sus métricas actuales y autores en lotes de hasta 100:
Ahorro: 100 publicaciones en 1 solicitud en lugar de 100: un 99 % menos.

Principio 3: Utiliza /list-tweets para varias cuentas

Agrupa cuentas en una lista de X y consulta su actividad reciente combinada con una llamada, en lugar de consultar cada cuenta.
Estimación para primeras páginas: una lista cada 10 segundos consume 259.200 solicitudes en 30 días, frente a 7.776.000 para 30 cronologías por separado. Las páginas adicionales y los reintentos aumentan ambos totales; una lista muy activa puede requerir paginación en cada ciclo. Consulta Supervisión en tiempo real y Listas y comunidades.

Principio 4: Utiliza /info para resolver perfiles

/info acepta nombre, ID o enlace de perfil y devuelve el perfil completo con el ID permanente. Es una opción flexible para normalizar entradas mixtas. Si necesitas perfiles completos, llama una vez por cuenta a /info, en lugar de convertir con /username-to-id o /link-to-id y después consultar el perfil:
Cuándo usar conversiones por separado: cuando solo necesitas el ID o el nombre, sin el perfil completo; por ejemplo, convertir 1.000 nombres a IDs para almacenarlos. Si ya tienes el perfil, reutiliza id sin otra solicitud. Consulta Conversión de IDs.

Principio 5: Elimina duplicados en la base de datos

El mismo usuario aparecerá en búsquedas, seguidores, menciones y cronologías. Utiliza su ID permanente como clave y actualiza registros existentes en lugar de insertar duplicados.
Así actualizas el perfil cada vez que aparece en una respuesta. Las cuentas que no vuelvan a aparecer no se actualizarán con este método. Programa actualizaciones por lotes si tu aplicación requiere una antigüedad máxima de datos.

Principio 6: No vuelvas a consultar datos que ya tienes

En flujos de varios pasos, transmite los datos de un paso al siguiente. Geografía de audiencias. Primero obtienes seguidores y después consultas /about para cada uno. Ya tienes su perfil completo: no vuelvas a llamar a /info. Solo necesitas /about para el país, que no está en el perfil estándar. Consulta Geografía de la audiencia. Verificación de campañas. Si /check-comment devuelve commented: true, incluye el comentario completo. Extrae su texto de esa respuesta para evaluar la calidad; no lo busques de nuevo con /search-tweets o /comments. Lista de usuarios desde una búsqueda. Si ya obtuviste 500 usuarios únicos de los objetos user, filtra localmente cuáles tienen más de 10.000 seguidores. No realices 500 llamadas a /info.

Referencia rápida: elegir el endpoint


Estimar el presupuesto de solicitudes

Calcula el volumen antes de empezar: Un flujo combinado puede consumir 50 + 10.000 + 1 + 8.640 + 5.000 = unas 23.700 solicitudes. A 20 por segundo, el mínimo teórico de procesamiento ronda los 20 minutos. Sin embargo, la supervisión abarca un día completo; la paginación secuencial, latencia y reintentos añaden tiempo. Consulta Precios para estimar el coste.

Próximos pasos