API de Actividad de la Cuenta: Enterprise

Este endpoint se ha actualizado para incluir metadatos de edición de Publicaciones. Obtén más información sobre estos metadatos en la página de conceptos básicos de “Editar Publicaciones”. Este endpoint se usa a menudo con los endpoints de Mensajes Directos. Hemos lanzado nuevos endpoints v2 de Mensajes Directos. Ten en cuenta que las APIs de Actividad de la Cuenta Enterprise y Premium son compatibles con mensajes uno a uno de v2, pero aún no admiten conversaciones de grupo.

Descripción general Enterprise La API de Actividad de la Cuenta te permite suscribirte a actividades en tiempo real relacionadas con una cuenta de usuario mediante webhooks. Esto significa que puedes recibir Publicaciones en tiempo real, Mensajes Directos y otros eventos de cuenta desde una o varias de tus cuentas propias o a las que estés suscrito, a través de una única conexión. Recibirás todas las actividades relacionadas que se indican a continuación para cada suscripción de usuario en tu registro de webhook:

Tipos de actividad
* Publicaciones (del usuario) * Eliminaciones de Publicaciones (del usuario) * Menciones @ (del usuario) * Respuestas (al usuario o del usuario) * Retweets (del usuario o sobre el usuario) * Tweets citados (del usuario o sobre el usuario) * Retweets de Tweets citados (del usuario o sobre el usuario) * Me gusta (del usuario o sobre el usuario) * Seguimientos (del usuario o hacia el usuario) * Dejar de seguir (del usuario)	* Bloqueos (del usuario) * Desbloqueos (del usuario) * Silenciamientos (del usuario) * Reactivaciones de silencio (del usuario) * Mensajes Directos enviados (por el usuario) * Mensajes Directos recibidos (por el usuario) * Indicadores de escritura (para el usuario) * Confirmaciones de lectura (para el usuario) * Revocaciones de suscripción (por el usuario)

Ten en cuenta - No entregamos datos de la cronología principal a través de la API de Actividad de la Cuenta. Usa GET statuses/home_timeline para obtener estos datos.

Serie de videos

Consulta nuestra serie de videos en cuatro partes sobre la API Account Activity para ponerte al día.

Resumen de funciones

Nivel	Precio	Número de suscripciones únicas	Número de webhooks	Fiabilidad y recuperación de actividad
Enterprise	Contactar con el equipo de ventas	Hasta 500+	3+	Reintentos y Replay

¿Tienes preguntas? ¿Te estás encontrando con errores?
- Lee nuestras preguntas frecuentes o la guía de resolución de errores.
Explora nuestro código de ejemplo:
- Enterprise Account Activity API dashboard, una aplicación web en Node que muestra eventos de webhook utilizando el nivel Enterprise de la Account Activity API e incluye la funcionalidad de Replay.
- El SnowBot chatbot, una aplicación web en Ruby creada sobre las APIs empresariales de Account Activity y Direct Message.

Administrar webhooks y usuarios suscritos

⏱ Lectura de 10 minutos La API empresarial Account Activity te proporciona mensajes JSON basados en webhooks cada vez que se producen eventos asociados con cuentas de X suscritas a tu servicio. X entrega esas actividades a tu webhook registrado. En los siguientes pasos, aprenderás cómo administrar webhooks y usuarios suscritos. Aprenderás cómo registrar, ver y eliminar tanto webhooks como usuarios suscritos. Usaremos comandos cURL simples para hacer solicitudes a los distintos endpoints de la API. cURL es una herramienta de línea de comandos para enviar o recibir solicitudes utilizando la sintaxis de URL. Necesitarás:

Una App registrada en X - regístrate aquí
Un Bearer Token - más información
Un webhook que pase un Challenge-Response Check (CRC) - más información
Una cuenta enterprise - [solicítala aquí]https://developer.x.com/en/products/x-api/enterprise

Antes de comenzar, te recomendamos que revises nuestro repositorio de GitHub aquí, que proporciona una aplicación web de ejemplo y scripts auxiliares para empezar a trabajar con la API Account Activity de X

Administrar un webhook:

Usar un webhook permite suscribirse a actividades en tiempo real relacionadas con la cuenta de un usuario a través de una única conexión.

Agregar un webhook
Ver un webhook
Eliminar un webhook

Comencemos registrando una nueva URL de webhook para el contexto de la aplicación indicado.La URL se validará mediante una solicitud CRC antes de guardarla. Una vez que hayas registrado un webhook, asegúrate de documentar el ID del webhook, ya que lo necesitarás más adelante.Copia la siguiente solicitud de cURL en tu línea de comandos tras sustituir los siguientes valores:

URL <URL> p. ej. https://yourdomain.com/webhooks/twitter/
Consumer key <CONSUMER_KEY> p. ej. xvz1evFS4wEEPTGEFPHBog

Access token <ACCESS_TOKEN> p. ej. 370773112-GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb

curl --request POST --url 'https://api.x.com/1.1/account_activity/webhooks.json?url=<URL>' --header 'authorization: OAuth oauth_consumer_key="<CONSUMER_KEY>", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="<ACCESS_TOKEN>", oauth_version="1.0"'

Ejecutaremos el siguiente comando, que devuelve todas las URL de webhook registradas y sus estados para la aplicación indicada.Copia la siguiente solicitud de cURL en tu línea de comandos tras sustituir los siguientes valores:

Bearer Token <BEARER_TOKEN> p. ej. AAAAAAAAAAAA0%2EUifi76ZC9Ub0wn...
--request GET --url https://api.x.com/1.1/account_activity/webhooks.json --header

Para eliminar un webhook de la configuración de la aplicación indicada, copia la siguiente solicitud de cURL en tu línea de comandos tras sustituir los siguientes valores:

Webhook ID <:WEBHOOK_ID> p. ej. 1234567890
Consumer key <CONSUMER_KEY> p. ej. xvz1evFS4wEEPTGEFPHBog
Access token <ACCESS_TOKEN> p. ej. 370773112-GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb
--request DELETE --url https://api.x.com/1.1/account_activity/webhooks/<:WEBHOOK_ID>.json --header

Gestión de usuarios suscritos:

Una vez que hayas registrado un Webhook, puedes agregar un usuario suscrito a la Account Activity API para comenzar a recibir la actividad de su cuenta.

Agregar una suscripción
Ver suscripciones
Eliminar una suscripción

Comenzaremos suscribiendo a un usuario para que recibas todos los tipos de evento.Copia la siguiente solicitud cURL en tu línea de comandos después de realizar cambios en lo siguiente:

Webhook ID <:WEBHOOK_ID> p. ej. 1234567890
Nombre de la consumer key <CONSUMER_KEY> p. ej. xvz1evFS4wEEPTGEFPHBog

Token de acceso del usuario suscrito <SUBSCRIBING_USER'S_ACCESS_TOKEN> p. ej. 370773112-GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb

curl --request POST --url https://api.x.com/1.1/account_activity/webhooks/<:WEBHOOK_ID>/subscriptions/all.json --header 'authorization: OAuth oauth_consumer_key="<CONSUMER_KEY>", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="<SUBSCRIBING_USER'S_ACCESS_TOKEN>", oauth_version="1.0"'

Para ver una lista de todas las suscripciones a tipos de actividad para un webhook especificado, copia la siguiente solicitud cURL en tu línea de comandos después de realizar cambios en lo siguiente:

Webhook ID <:WEBHOOK_ID> p. ej. 1234567890

Bearer Token <BEARER_TOKEN> p. ej. AAAAAAAAAAAA0%2EUifi76ZC9Ub0wn...

curl --request GET --url https://api.x.com/1.1/account_activity/webhooks/<:WEBHOOK_ID>/subscriptions/all/list.json --header 'authorization: Bearer <BEARER_TOKEN>'

Después de la desactivación, todos los eventos del usuario solicitante dejarán de enviarse a la URL del webhook.Para desactivar una suscripción desde el contexto del usuario y la aplicación proporcionados, copia la siguiente solicitud cURL en tu línea de comandos después de realizar cambios en lo siguiente:

Webhook ID <:WEBHOOK_ID> p. ej. 1234567890
Consumer key <CONSUMER_KEY> p. ej. xvz1evFS4wEEPTGEFPHBog

Token de acceso del usuario suscrito <SUBSCRIBING_USER'S_ACCESS_TOKEN> p. ej. 370773112-GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb

curl --request DELETE --url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID/subscriptions/all.json --header 'authorization: OAuth oauth_consumer_key="CONSUMER_KEY", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="SUBSCRIBED_USER'S_ACCESS_TOKEN", oauth_version="1.0"'

¡Buen trabajo! Ahora ya deberías poder gestionar tus webhooks y usuarios suscritos.

Un recorrido en video por la Account Activity API

En este recorrido en video, aprenderás sobre las funcionalidades de los niveles premium y enterprise de la Account Activity API. Al final de este video, habrás aprendido las siguientes funcionalidades:

Registrar un webhook
Agregar una suscripción de usuario
Eliminar una suscripción de usuario
Recibir actividades de cuenta
Reproducir actividades de cuenta

¿Tienes preguntas? ¿Te estás encontrando con errores?
- Lee nuestras preguntas frecuentes o la guía de solución de errores.
Explora nuestro código de ejemplo:
- Panel de la Enterprise Account Activity API, una app web de Node que muestra eventos de webhook usando el nivel enterprise de la Account Activity API e incluye funcionalidad de Replay.
- El chatbot SnowBot, una app web de Ruby creada sobre las Enterprise Account Activity y Direct Message APIs.

Enterprise

Introducción a los webhooks

La Account Activity API es una API basada en webhooks que envía eventos de cuenta a una aplicación web que desarrollas, despliegas y alojas. Hay varios detalles de infraestructura que requieren atención antes de que puedas empezar a recibir eventos de webhook en tu aplicación que consume eventos. Como se describe a continuación, deberás crear una App de X, obtener acceso a la Account Activity API y desarrollar una aplicación web que consuma eventos de webhook.

1. Crea una App de X.

Crea una App de X con una cuenta de desarrollador aprobada en la Consola de desarrollador. Si estás creando la App en nombre de tu empresa, se recomienda que la crees con una cuenta corporativa de X. Para solicitar una cuenta de desarrollador, haz clic aquí.
Habilita “Read, Write and Access direct messages” en la pestaña de permissions de la página de tu App.
En la pestaña “Keys and Access Tokens”, toma nota de la Consumer Key (API Key) y del Consumer Token (API Secret) de tu App.
En la misma pestaña, genera el Access Token y Access Token Secret de tu App. Necesitarás estos Access Tokens para registrar la URL de tu webhook, que es donde X enviará los eventos de cuenta.
Si no estás familiarizado con X Sign-in y cómo funcionan los contextos de usuario con X API, revisa Obtaining Access Tokens. A medida que vayas agregando cuentas para recibir eventos, las suscribirás usando los Access Tokens de esa cuenta.
Toma nota del ID numérico de tu App, tal como aparece en la página “Apps” de la Consola de desarrollador. Cuando solicites acceso a Account Activity API, necesitarás este id de la App.

2. Obtener acceso a Account Activity API

Después de crear una App de X, el siguiente paso es solicitar acceso a Account Activity API. Account Activity API solo está disponible en Enterprise, por lo que deberás enviar una solicitud usando el siguiente enlace.

3. Desarrollar la aplicación consumidora de webhooks

Una vez que hayas recibido acceso a la Account Activity API, debes desarrollar, desplegar y alojar una aplicación web que reciba eventos de webhook de X.

Crea una aplicación web con una URL para usarla como tu webhook para recibir eventos. Este es el endpoint desplegado en tu servidor que escucha los eventos de webhook entrantes de X.
- La ruta (path) del URI depende completamente de ti. Este ejemplo sería válido: https://mydomain.com_/service/listen_
- Si estás recibiendo webhooks de diversas fuentes, un patrón común es: https://mydomain.com/webhook/twitter
- Ten en cuenta que la URL especificada no puede incluir una especificación de puerto (https://mydomain.com:5000/NoWorkie).
Como se describe en nuestra guía de Protección de webhooks, un primer paso es escribir código que reciba una solicitud GET de X Challenge Response Check (CRC) y responda con una respuesta JSON correctamente formateada.
Registra la URL de tu webhook. Realizarás una solicitud POST al endpoint /webhooks.json?url=. Cuando realices esta solicitud, X enviará una solicitud CRC a tu aplicación web. Cuando un webhook se registra correctamente, la respuesta incluirá un webhook id. Este webhook id es necesario más adelante al realizar algunas solicitudes a la Account Activity API.
X enviará eventos de webhook de cuenta a la URL que registraste. Asegúrate de que tu aplicación web acepte solicitudes POST para los eventos entrantes. Estos eventos estarán codificados en JSON. Consulta aquí para ver ejemplos de payloads JSON de webhooks.
Una vez que tu aplicación web esté lista, el siguiente paso es agregar cuentas para las que recibir actividades. Al agregar (o eliminar) cuentas, realizarás solicitudes POST que hagan referencia al id de la cuenta. Consulta nuestra guía sobre cómo agregar suscripciones para obtener más información.

4. Validar la configuración

Para validar que tu app y webhook están configurados correctamente, marca como favorito una Publicación de una de las cuentas de X a las que está suscrita tu app. Deberías recibir un favorite_events mediante una solicitud POST a la URL de tu webhook por cada Favorito que reciban tus suscriptores.
Ten en cuenta que pueden transcurrir hasta 10 segundos antes de que los eventos comiencen a entregarse después de agregar una suscripción.

Notas importantes

Al registrar la URL de tu webhook, tu aplicación web debe autenticarse con su token y secreto de consumidor y el token y secreto de acceso de usuario del propietario de la app.
Todos los Mensajes Directos entrantes se entregarán mediante webhooks. Todos los Mensajes Directos enviados a través de POST direct_messages/events/new (message_create) también se entregarán mediante webhooks. Esto es para que tu aplicación web pueda conocer los Mensajes Directos enviados a través de un cliente diferente.
Ten en cuenta que cada evento de webhook incluye un ID de usuario for_user_id que indica para qué suscripción se entregó el evento.
Si tienes a dos usuarios usando tu aplicación web para Mensajes Directos en la misma conversación, tu webhook recibirá dos eventos duplicados (uno por cada usuario). Tu aplicación web debe tener esto en cuenta.
Si tienes más de una aplicación web que comparte la misma URL de webhook y el mismo usuario asignado a cada app, el mismo evento se enviará a tu webhook múltiples veces (una por cada aplicación web).
En algunos casos, tu webhook puede recibir eventos duplicados. Tu aplicación de webhook debe ser tolerante a esto y eliminar duplicados usando el ID del evento.
No esperes que la respuesta de Quick Reply siga directamente a una solicitud. Un usuario puede ignorar una solicitud de Quick Reply y responder mediante un Mensaje Directo tradicional. El usuario también puede proporcionar una respuesta de Quick Reply a una solicitud a la que no haya respondido anteriormente en el hilo de mensajes.
Consulta el código de ejemplo:
- Enterprise Account Activity API dashboard, una aplicación web de Node que muestra eventos de webhook usando el nivel empresarial de la Account Activity API e incluye funcionalidad de Replay.
- El chatbot SnowBot, una aplicación web en Ruby creada sobre las Account Activity y Direct Message APIs. Esta base de código incluye un script para ayudar a configurar los webhooks de la Account Activity API.

Proteger los webhooks

Las APIs basadas en webhooks de X ofrecen dos métodos para confirmar la seguridad de tu servidor de webhooks:

Las comprobaciones de desafío-respuesta permiten a X confirmar la propiedad de la aplicación web que recibe los eventos de webhook.
El encabezado de firma en cada solicitud POST te permite confirmar que X es el origen de los webhooks entrantes.

Comprobaciones de desafío-respuesta

Para verificar que eres tanto el propietario de la App como de la URL del webhook, X realizará una comprobación de desafío-respuesta (CRC), que no debe confundirse con una comprobación de redundancia cíclica. Cuando se envía un CRC, X realizará una solicitud GET a tu aplicación web con un parámetro crc_token. Cuando se reciba esa solicitud, tu aplicación web deberá generar un response_token cifrado basado en el parámetro crc_token y en el Consumer Secret de tu App (detalles a continuación). El response_token debe estar codificado en JSON (consulta el ejemplo a continuación) y devolverse en un plazo de tres segundos. Cuando la operación se completa correctamente, se devolverá un id de webhook. Se enviará un CRC cuando registres tu URL de webhook, por lo que implementar tu código de respuesta de CRC es un primer paso fundamental. Una vez que tu webhook esté establecido, X activará un CRC aproximadamente cada 24 horas desde la última vez que recibimos una respuesta correcta. Tu App también puede activar un CRC cuando sea necesario realizando una solicitud PUT con el id de tu webhook. Activar un CRC es útil mientras desarrollas tu aplicación de webhook, después de implementar nuevo código y reiniciar tu servicio. Debes esperar que el crc_token cambie en cada solicitud CRC entrante y debes utilizarlo como mensaje en el cálculo, donde tu Consumer Secret es la clave. En caso de que la respuesta no se envíe en un plazo de 3 segundos o deje de ser válida, se dejarán de enviar eventos al webhook registrado.

La solicitud de CRC se producirá:

Cuando se registre una URL de webhook.
Aproximadamente cada hora para validar tu URL de webhook.
Puedes activar manualmente un CRC haciendo una solicitud PUT. A medida que desarrolles tu cliente de webhook, deberías planear activar manualmente el CRC mientras desarrollas tu respuesta al CRC.

Requisitos de la respuesta:

Un hash HMAC SHA-256 codificado en Base64 creado a partir del crc_token y el Consumer Secret de tu aplicación.
response_token válido y en formato JSON.
Latencia menor a 3 segundos.
Código de respuesta HTTP 200.

Bibliotecas HMAC específicas del lenguaje:

Ejemplo de generación de token de respuesta en Python:

Lo siguiente define una ruta en una aplicación web Flask en Python 2.7 que responderá correctamente a la verificación de respuesta al desafío.

import base64
import hashlib
import hmac
import json


\# Define una ruta para la solicitud GET
@app.route('/webhooks/twitter', methods=\['GET'\])
def webhook_challenge():

  # crea un hash HMAC SHA-256 a partir del token entrante y tu clave secreta de consumidor
  sha256\_hash\_digest = hmac.new(TWITTER\_CONSUMER\_SECRET, msg=request.args.get('crc_token'), digestmod=hashlib.sha256).digest()

  # construye los datos de respuesta con el hash codificado en base64
  response = {
    'response\_token': 'sha256=' + base64.b64encode(sha256\_hash_digest)
  }

  # devuelve una respuesta JSON con el formato adecuado
  return json.dumps(response)

Ejemplo de respuesta JSON:

Con la ruta definida como se indica arriba, tu aplicación web debería devolver una respuesta similar a la siguiente al acceder a https://your-app-domain/webhooks/twitter?crc_token=foo en tu navegador web.

{
  "response_token": "sha256=x0mYd8hz2goCTfcNAaMqENy2BFgJJfJOb4PdvTffpwg="
}

Otros ejemplos:

AQUÍ hay un ejemplo de método de respuesta CRC escrito en Node.js.
AQUÍ hay un ejemplo de método de respuesta CRC escrito en Ruby (consulta generate_crc_response y la ruta /GET que recibe eventos CRC).

Validación opcional del encabezado de firma

Cuando recibes una solicitud POST de X, envías una solicitud GET para crear un webhook o envías una solicitud GET para realizar un CRC manual, se incluirá una firma hash en los encabezados como x-twitter-webhooks-signature. Esta firma se puede usar para validar que el origen de los datos es X. La firma hash de la solicitud POST comienza con sha256=, lo que indica el uso de HMAC SHA-256 para cifrar tu X App Consumer Secret y el payload. El hash de la solicitud GET se calcula a partir de la cadena de parámetros de consulta crc_token=

token&amp;nonce=

nonce. Pasos para validar una solicitud

Genera un hash usando tu consumer secret y el cuerpo del payload entrante.
Compara el hash generado con el valor x-twitter-webhooks-signature codificado en base64. Usa un método como compare_digest para reducir la vulnerabilidad a ataques de temporización.

Directrices de seguridad adicionales

A continuación se presentan directrices de seguridad adicionales que debes considerar para tu aplicación web. No implementar estas directrices no impedirá que tu webhook funcione, pero son muy recomendadas por el equipo de Seguridad de la Información de X. Si no estás familiarizado con las siguientes recomendaciones, consulta con el administrador de tu servidor.

Bloques de red agregados de X

Para mayor seguridad, puedes agregar los siguientes bloques de red agregados a una lista de permitidos:

199.59.148.0/22
199.16.156.0/22
192.133.77.0/26
64.63.15.0/24
64.63.31.0/24
64.63.47.0/24
202.160.128.0/24
202.160.129.0/24
202.160.130.0/24

Configuraciones de servidor recomendadas

Obtener una calificación “A” en la prueba de ssllabs.com
Habilitar TLS 1.2
Habilitar Forward Secrecy
Desactivar SSLv2
Desactivar SSLv3 (debido a POODLE)
Desactivar TLS 1.0
Desactivar TLS 1.1
Desactivar la compresión TLS
Desactivar Session Tickets a menos que se roten las claves de Session Tickets.
Establecer la opción “ssl_prefer_server_ciphers” o “SSLHonorCipherOrder” en la configuración SSL como “on”.
Asegurarse de que la lista de cifrados sea moderna, por ejemplo: ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:DES-CBC3-SHA

Administrar webhooks y suscripciones

Creación y actualización de webhooks

Para cambiar las URL de un webhook, deberás eliminar tu webhook existente y luego crear uno nuevo. Ten en cuenta que, al hacerlo, tendrás que volver a añadir las suscripciones de usuario al nuevo webhook.

Endpoints de administración de la configuración de webhooks:


Método	Enterprise
Registra una URL de webhook / Genera un webhook_id	POST webhooks
Devuelve todas las URL de webhook y sus estados	GET webhooks
Elimina la configuración de webhook actual de la aplicación	DELETE webhooks/:webhook_id
Activa manualmente una solicitud CRC	PUT webhooks/:webhook_id

¿Por qué no puedo simplemente actualizar la URL del webhook?

¿Por qué las configuraciones de webhook son inmutables? X se toma la seguridad muy en serio. Si se cambia la URL de tu webhook, existe la posibilidad de que la consumer key y el consumer secret de tu aplicación se hayan visto comprometidos. Al obligarte a crear una nueva configuración de webhook, también debes volver a suscribirte a los eventos de tu usuario. Esto requiere el uso de tokens de acceso que es menos probable que una parte malintencionada posea. Como resultado, se reduce la probabilidad de que otra parte reciba la información privada de tu usuario.

Añadir y eliminar suscripciones de usuario

La compatibilidad con miles de suscripciones está disponible en el plan Enterprise. Si ya tienes un gestor de cuenta, comunícate con esa persona si tienes preguntas. Para solicitar acceso a las APIs Enterprise, haz clic aquí.

Endpoints para la gestión de suscripciones


Método	Enterprise
Añadir nueva suscripción de usuario	POST webhooks/:webhook_id/subscriptions/all
Obtener una suscripción de usuario	GET webhooks/:webhook_id/subscriptions/all
Devuelve una lista de todas las suscripciones activas	GET webhooks/:webhook_id/subscriptions/all/list
Desactiva una suscripción de usuario mediante OAuth solo de aplicación	DELETE webhooks/:webhook_id/subscriptions/:user_id/all.json

Account Activity API: Enterprise

Ten en cuenta lo siguiente: X debe habilitar el acceso a la Account Activity API para tu App de desarrollador antes de que puedas empezar a usar la API. Para ello, asegúrate de compartir el ID de la App que tienes previsto usar para la autenticación con tu gestor de cuenta o con tu equipo de soporte técnico.

La Account Activity API está compuesta por un conjunto de endpoints que te permiten crear y gestionar suscripciones de usuario para recibir actividad de cuenta en tiempo real de todas tus cuentas suscritas a través de una única conexión. Hay dos métodos de autenticación disponibles para la Account Activity API (OAuth 1.0a y OAuth 2.0 Bearer Token. El método de autenticación que debes usar dependerá del endpoint que estés utilizando.


Descripción	Endpoint	OAuth 1.0a (contexto de usuario)	OAuth 2.0 Bearer Token (solo aplicación)
Registrar una nueva URL de webhook para el contexto de aplicación dado	POST account_activity/webhooks	✓
Devolver todas las URLs y sus estados para la aplicación dada	GET account_activity/webhooks		✓
Ejecutar una comprobación de respuesta de desafío (CRC) para la URL de un webhook dado	PUT account_activity/webhooks/:webhook_id	✓
Suscribir la aplicación a los eventos de cuenta de un usuario	POST account_activity/webhooks/:webhook_id/subscriptions/all	✓ *
Devolver un recuento de suscripciones actualmente activas	GET account_activity/subscriptions/count		✓
Comprobar si una configuración de webhook está suscrita a los eventos de un usuario	GET account_activity/webhooks/:webhook_id/subscriptions/all	✓ *
Devolver una lista de suscripciones actualmente activas	GET account_activity/webhooks/:webhook_id/subscriptions/all/list		✓
Eliminar un webhook	DELETE account_activity/webhooks/:webhook_id	✓
[OBSOLETO] Desactivar una suscripción para el contexto de usuario y la aplicación proporcionados	DELETE account_activity/webhooks/:webhook_id/subscriptions/all	✓ *
Desactivar una suscripción usando OAuth de solo aplicación	DELETE /account_activity/webhooks/:webhook_id/subscriptions/:user_id/all.json		✓
Reentregar actividades a un webhook	POST /1.1/account_activity/replay/webhooks/:webhook_id/subscriptions/all.json		✓

*_ La autenticación requiere los tokens de acceso del usuario suscriptor. _ Para aquellos endpoints que requieren autenticación OAuth 1.0a con contexto de usuario, debes proporcionar las siguientes credenciales para autenticar la solicitud:

Consumer Keys (API Key y Secret)
Access Tokens (Access Token y Secret)

En el caso de los siguientes tres endpoints, se realizan acciones de escritura dentro del contexto de tu aplicación (no intervienen usuarios de X). Por lo tanto, los Access Tokens que debes proporcionar son los que pertenecen a tu App de desarrollador. Estos se pueden generar directamente desde la Consola de desarrollador, en la pestaña “Keys and tokens” de tu App.

POST account_activity/webhooks: Registra una nueva URL de webhook para el contexto de aplicación indicado
PUT account_activity/webhooks/:webhook_id: Activa una verificación de respuesta al desafío (CRC) para la URL de un webhook dado
DELETE account_activity/webhooks/:webhook_id: Elimina un webhook

Por otro lado, en el caso de los siguientes tres endpoints, estás realizando una solicitud que permite que tu aplicación acceda a datos protegidos en nombre de un usuario de X (por ejemplo, Mensajes Directos). Por lo tanto, debes proporcionar los Access Tokens que pertenecen al usuario suscriptor en cuestión. Los Access Tokens requeridos se pueden obtener usando el flujo OAuth de 3 partes (consulta OAuth 1.0a: how to obtain a user’s Access Tokens). Estos endpoints se han marcado con un asterisco en la tabla anterior (*).

POST account_activity/webhooks/:webhook_id/subscriptions/all: Suscribe la aplicación a los eventos de la cuenta de un usuario
GET account_activity/webhooks/:webhook_id/subscriptions/all: Comprueba si una configuración de webhook está suscrita a los eventos de un usuario
DELETE account_activity/webhooks/:webhook_id/subscriptions/all: Desactiva una suscripción para el contexto de usuario y la aplicación proporcionados [OBSOLETO]

Please note: Asegúrate de que tu App de desarrollador esté habilitada para “Read, Write, and Direct Messages.” Puedes cambiar esta configuración en la sección Projects & Apps de tu cuenta de desarrollador, en “App permissions” para la App de desarrollador seleccionada. Deberás volver a generar las credenciales de tu App después de cambiar la configuración de permisos.

Puedes encontrar una lista de todos los endpoints disponibles con la Account Activity API, incluida la descripción asociada y ejemplos de solicitudes cURL con ejemplos de implementación de autenticación, en la documentación de Referencia de la API. Para obtener más información, consulta la aplicación web de ejemplo y scripts auxiliares de XDev para comenzar a usar la Enterprise Account Activity API.

Please note: X debe habilitar el acceso a la Account Activity API para tu App de desarrollador antes de que puedas empezar a usar la API. Para ello, asegúrate de compartir el App ID que piensas usar para fines de autenticación con tu account manager o con el equipo de soporte técnico.

La Account Activity API consta de un conjunto de endpoints que te permiten crear y administrar suscripciones de usuario para recibir actividades de cuenta en tiempo real para todas tus cuentas suscritas a través de una única conexión. Hay dos métodos de autenticación disponibles con la Account Activity API (OAuth 1.0a y OAuth 2.0 Bearer Token). El método de autenticación que debes usar dependerá de qué endpoint estés utilizando.


Descripción	Endpoint	OAuth 1.0a (contexto de usuario)	OAuth 2.0 Bearer Token (solo de aplicación)
Registrar una nueva URL de webhook para el contexto de aplicación especificado	POST account_activity/webhooks	✓
Devolver todas las URL y sus estados para la aplicación especificada	GET account_activity/webhooks		✓
Iniciar una comprobación de respuesta de desafío (CRC) para la URL de un webhook determinado	PUT account_activity/webhooks/:webhook_id	✓
Suscribir la aplicación a los eventos de cuenta de un usuario	POST account_activity/webhooks/:webhook_id/subscriptions/all	✓ *
Devolver el número de suscripciones activas actualmente	GET account_activity/subscriptions/count		✓
Comprobar si una configuración de webhook está suscrita a los eventos de un usuario	GET account_activity/webhooks/:webhook_id/subscriptions/all	✓ *
Devolver una lista de suscripciones activas actualmente	GET account_activity/webhooks/:webhook_id/subscriptions/all/list		✓
Eliminar un webhook	DELETE account_activity/webhooks/:webhook_id	✓
[OBSOLETO] Desactivar una suscripción para el contexto de usuario y la aplicación proporcionados	DELETE account_activity/webhooks/:webhook_id/subscriptions/all	✓ *
Desactivar una suscripción usando OAuth de solo aplicación	DELETE /account_activity/webhooks/:webhook_id/subscriptions/:user_id/all.json		✓
Volver a enviar actividades a un webhook	POST /1.1/account_activity/replay/webhooks/:webhook_id/subscriptions/all.json		✓

*_ La autenticación requiere los tokens de acceso del usuario suscriptor. _ Para aquellos endpoints que requieren autenticación OAuth 1.0a con contexto de usuario, deberás proporcionar las siguientes credenciales para autenticar la solicitud:

Consumer Keys (API Key y Secret)
Access Tokens (Access Token y Secret)

En el caso de los tres endpoints siguientes, realizas acciones de escritura dentro del contexto de tu aplicación (no se involucran usuarios de X). Por lo tanto, los Access Tokens que debes proporcionar son los que pertenecen a tu App de desarrollador. Estos se pueden generar directamente desde la Consola de desarrollador, en la pestaña “Keys and tokens” de tu App.

POST account_activity/webhooks: Registrar una nueva URL de webhook para el contexto de aplicación indicado
PUT account_activity/webhooks/:webhook_id: Ejecutar una comprobación de respuesta de desafío (CRC) para la URL de un webhook dado
DELETE account_activity/webhooks/:webhook_id: Eliminar un webhook

Por otro lado, en el caso de los siguientes tres endpoints, estás realizando una solicitud que permite que tu aplicación acceda a datos protegidos en nombre de un usuario de X (por ejemplo, Mensajes Directos). Por lo tanto, debes proporcionar los Access Tokens que pertenecen al usuario suscriptor en cuestión. Los Access Tokens requeridos se pueden obtener utilizando el flujo OAuth de 3 patas (consulta OAuth 1.0a: cómo obtener los Access Tokens de un usuario). Estos endpoints se han marcado con un asterisco en la tabla anterior (*).

POST account_activity/webhooks/:webhook_id/subscriptions/all: Suscribir la aplicación a los eventos de la cuenta de un usuario
GET account_activity/webhooks/:webhook_id/subscriptions/all: Comprobar si una configuración de webhook está suscrita a los eventos de un usuario
DELETE account_activity/webhooks/:webhook_id/subscriptions/all: Desactivar una suscripción para el contexto de usuario y la aplicación proporcionados [OBSOLETO]

Ten en cuenta: Asegúrate de que tu App de desarrollador esté habilitada para “Read, Write, and Direct Messages.” Puedes cambiar esta configuración en la sección Projects & Apps de tu cuenta de desarrollador, en “App permissions” para la App de desarrollador seleccionada. Deberás volver a generar las credenciales de tu App después de cambiar la configuración de permisos.

Puedes encontrar una lista de todos los endpoints disponibles con la Account Activity API, incluida la descripción asociada y ejemplos de solicitudes cURL con ejemplos de implementación de autenticación, en la documentación de Referencia de la API. Para obtener información adicional, consulta la aplicación web de ejemplo y los scripts auxiliares de XDev para comenzar con la Enterprise Account Activity API.

Reintentos

Enterprise Uno de los beneficios del nivel Enterprise de la Account Activity API es un mecanismo de reintento para eventos de webhook. Si no se recibe un código de respuesta HTTP 200 de “success”, el servidor de X iniciará un mecanismo de reintento y reenviará el evento de webhook hasta tres veces durante un período de cinco minutos. Este servicio de reintento de eventos de webhook ayuda a proporcionar fiabilidad y recuperación de eventos cuando se producen problemas de red y durante interrupciones y despliegues del servicio en el lado del cliente.

¿Qué son los reintentos?

La API Account Activity proporciona una función de reintento cuando la aplicación web del cliente no devuelve una respuesta 200 de “success” para un evento de webhook de actividad de cuenta. Cuando el lado del cliente no confirma la recepción correcta de un evento, X asume que el evento no se recibió. Si se recibe una respuesta distinta de 200, no se recibe una respuesta en un plazo de tres segundos o no recibimos ninguna respuesta en absoluto, volvemos a intentar la solicitud y la mantenemos abierta durante tres segundos. Esto significa que tienes aproximadamente cinco segundos, repartidos en dos intentos, para responder y recibir la actividad que estamos intentando enviar a tu URL de webhook. En el caso de que tu servidor no responda o devuelva un error transitorio, volveremos a intentarlo durante cinco minutos. Habrá un total de tres intentos de reintento para confirmar la validación. Esto proporciona redundancia y sirve como garantía de que recibes todos los eventos de webhook. Ten en cuenta que las suscripciones con reintentos recibirán eventos reintentados para cualquiera/todas las actividades de todos los usuarios suscritos en su webhook. Si no confirmas la validación dentro de estos ocho intentos, la actividad ya no estará disponible a través de la API Account Activity.

Cronograma de reintentos

La Account Activity API intentará reenviar hasta tres veces durante un período de cinco minutos, hasta que se reciba una respuesta 200. Consulta la siguiente tabla para obtener más detalles. Transcurridos aproximadamente cinco minutos, la actividad ya no se puede volver a enviar a través de la Account Activity API. Deberás usar otros endpoints de X para recopilar los datos que falten. Por ejemplo, las APIs de búsqueda pueden utilizarse para recuperar Publicaciones relevantes, Retweets, Tweets citados, menciones y respuestas. Los Mensajes Directos que se hayan perdido pueden recuperarse con este endpoint.

Cronograma de reintentos


Actividad creada, se realiza un POST a la URL del webhook desde la API de Account Activity y el tiempo de espera se agota en tres segundos.
Espera tres segundos después de que finalice el tiempo de espera anterior, luego realiza un POST a la URL del webhook desde la API de Account Activity y el tiempo de espera se agota en tres segundos.
Espera 27 segundos después de que finalice el tiempo de espera anterior, luego realiza un POST a la URL del webhook desde la API de Account Activity y el tiempo de espera se agota en tres segundos.
Espera 242 segundos después de que finalice el tiempo de espera anterior, luego realiza un POST a la URL del webhook desde la API de Account Activity y el tiempo de espera se agota en tres segundos.
La API de Account Activity dejará de intentar realizar solicitudes POST después de esto. El Client debe usar otros endpoints de X para recuperar los datos.

Estructura del objeto de datos de Account Activity

Object	Details
for_user_id	Identifica la suscripción de usuario a la que está asociado el evento.
is_blocked_by	(condicional) Se muestra solo cuando otro usuario menciona a tu usuario suscrito. Se incluye si es true únicamente para eventos de mención de Publicaciones.
source	El usuario que está realizando la actividad. Por ejemplo, el usuario que sigue, bloquea o silencia es el usuario de origen.
target	El usuario al que se aplica la actividad. Por ejemplo, el usuario que está siendo seguido, bloqueado o silenciado es el usuario de destino.

Actividades disponibles

Message Type	Details
tweet_create_events	Carga útil del estado de la Publicación cuando se realiza cualquiera de las siguientes acciones por o hacia el usuario de la suscripción: Publicaciones, Retweets, respuestas, @menciones, QuoteTweets, Retweet de Quote Tweets.
favorite_events	Evento de favorito (Me gusta) con el usuario y el destino.
follow_events	Evento de seguir con el usuario y el destino.
unfollow_events	Evento de dejar de seguir con el usuario y el destino.
block_events	Evento de bloqueo con el usuario y el destino.
unblock_events	Evento de desbloqueo con el usuario y el destino.
mute_events	Evento de silenciamiento con el usuario y el destino.
unmute_events	Evento de dejar de silenciar con el usuario y el destino.
user_event	Eventos de revocación enviados cuando un usuario elimina la autorización de la aplicación y la suscripción se elimina automáticamente.
direct_message_events	Estado de mensaje directo con el usuario y el destino cuando se envía o se recibe un mensaje directo.
direct_message_indicate_typing_events	Evento de escritura de mensaje directo con el usuario y el destino.
direct_message_mark_read_events	Evento de lectura de mensaje directo con el usuario y el destino.
tweet_delete_events	Aviso de Publicaciones eliminadas para facilitar el mantenimiento del cumplimiento normativo.

Ejemplos de carga útil Consulta los siguientes ejemplos de carga útil para cada evento de Account Activity descrito en la tabla anterior.

tweet_create_events (Publicaciones, Retweets, Respuestas, Tweets citados)

{
	"for_user_id": "2244994945",
	"tweet_create_events": [
	  {
		<Tweet Object>
	  }
	]
}

tweet_create_events (@menciones)

{
	"for_user_id": "2244994945",
	"user_has_blocked": "false",
	"tweet_create_events": [
	  {
		<Tweet Object>
	  }
	]
}

favorite_events

{
	"for_user_id": "2244994945",
	"favorite_events": [{
		"id": "a7ba59eab0bfcba386f7acedac279542",
		"created_at": "Mon Mar 26 16:33:26 +0000 2018",
		"timestamp_ms": 1522082006140,
		"favorited_status": {
			<Tweet Object>
		},
		"user": {
			<User Object>
		}
	}]
}

follow_events

{
	"for_user_id": "2244994945",
	"follow_events": [{
			"type": "follow",
			"created_timestamp": "1517588749178",
			"target": {
				<User Object >
			},
			"source": {
				< User Object >
			}
		]
	}
}

unfollow_events

{
	"for_user_id": "2244994945",
	"follow_events": [{
			"type": "unfollow",
			"created_timestamp": "1517588749178",
			"target": {
				<User Object >
			},
			"source": {
				< User Object >
			}
		]
	}
}

block_events

{
	"for_user_id": "2244994945",
	"block_events": [{
		"type": "block",
		"created_timestamp": "1518127020304",
		"source": {
			<User Object>
		},
		"target": {
			<User Object>
		}
	}]
}

unblock_events

{
	"for_user_id": "2244994945",
	"block_events": [{
		"type": "unblock",
		"created_timestamp": "1518127020304",
		"source": {
			<User Object>
		},
		"target": {
			<User Object>
		}
	}]
}

mute_events

{
	"for_user_id": "2244994945",
	"mute_events": [
		{
			"type": "mute",
		  	"created_timestamp": "1518127020304",
			"source": {
				<User Object>
			},
			"target": {
				<User Object>
			}
		}
	]
}

unmute_events

{
	"for_user_id": "2244994945",
	"mute_events": [
		{
			"type": "unmute",
		  	"created_timestamp": "1518127020304",
			"source": {
				<User Object>
			},
			"target": {
				<User Object>
			}
		}
	]
}

user_event

{
	"user_event": {
		"revoke": {
			"date_time": "2018-05-24T09:48:12+00:00",
			"target": {
				"app_id": "13090192"
			},
			"source": {
				"user_id": "63046977"
			}
		}
	}
}

direct_message_events

{
  	"for_user_id": "4337869213",
	"direct_message_events": [{
		"type": "message_create",
		"id": "954491830116155396",
		"created_timestamp": "1516403560557",
		"message_create": {
			"target": {
				"recipient_id": "4337869213"
			},
			"sender_id": "3001969357",
			"source_app_id": "13090192",
			"message_data": {
				"text": "Hello World!",
				"entities": {
					"hashtags": [],
					"symbols": [],
					"user_mentions": [],
					"urls": []
				}
			}
		}
	}],
	"apps": {
		"13090192": {
			"id": "13090192",
			"name": "FuriousCamperTestApp1",
			"url": "https://x.com/furiouscamper"
		},
		"users": {},
		"3001969357": {
			"id": "3001969357",
			"created_timestamp": "1422556069340",
			"name": "Jordan Brinks",
			"screen_name": "furiouscamper",
			"location": "Boulder, CO",
			"description": "Alter Ego - X PE opinions-are-my-own",
			"url": "https://t.co/SnxaA15ZuY",
			"protected": false,
			"verified": false,
			"followers_count": 22,
			"friends_count": 45,
			"statuses_count": 494,
			"profile_image_url": "null",
			"profile_image_url_https": "https://pbs.twimg.com/profile_images/851526626785480705/cW4WTi7C_normal.jpg"
		},
		"4337869213": {
			"id": "4337869213",
			"created_timestamp": "1448312972328",
			"name": "Harrison Test",
			"screen_name": "Harris_0ff",
			"location": "Burlington, MA",
			"protected": false,
			"verified": false,
			"followers_count": 8,
			"friends_count": 8,
			"profile_image_url": "null",
			"statuses_count": 240,
			"profile_image_url_https": "https://abs.twimg.com/sticky/default_profile_images/default_profile_normal.png"
		}
	}
}

direct_message_indicate_typing_events

{
	"for_user_id": "4337869213",
	"direct_message_indicate_typing_events": [{
		"created_timestamp": "1518127183443",
		"sender_id": "3284025577",
		"target": {
			"recipient_id": "3001969357"
		}
	}],
	"users": {
		"3001969357": {
			"id": "3001969357",
			"created_timestamp": "1422556069340",
			"name": "Jordan Brinks",
			"screen_name": "furiouscamper",
			"location": "Boulder, CO",
			"description": "Alter Ego - X PE las-opiniones-son-mías",
			"url": "https://t.co/SnxaA15ZuY",
			"protected": false,
			"verified": false,
			"followers_count": 23,
			"friends_count": 47,
			"statuses_count": 509,
			"profile_image_url": "null",
			"profile_image_url_https": "https://pbs.twimg.com/profile_images/851526626785480705/cW4WTi7C_normal.jpg"
		},
		"3284025577": {
			"id": "3284025577",
			"created_timestamp": "1437281176085",
			"name": "Bogus Bogart",
			"screen_name": "bogusbogart",
			"protected": true,
			"verified": false,
			"followers_count": 1,
			"friends_count": 4,
			"statuses_count": 35,
			"profile_image_url": "null",
			"profile_image_url_https": "https://pbs.twimg.com/profile_images/763383202857779200/ndvZ96mE_normal.jpg"
		}
	}
}

direct_message_mark_read_events

{
	"for_user_id": "4337869213",
	"direct_message_mark_read_events": [{
		"created_timestamp": "1518452444662",
		"sender_id": "199566737",
		"target": {
			"recipient_id": "3001969357"
		},
		"last_read_event_id": "963085315333238788"
	}],
	"users": {
		"199566737": {
			"id": "199566737",
			"created_timestamp": "1286429788000",
			"name": "Le Braat",
			"screen_name": "LeBraat",
			"location": "Denver, CO",
			"description": "data by day @X, design by dusk",
			"protected": false,
			"verified": false,
			"followers_count": 299,
			"friends_count": 336,
			"statuses_count": 752,
			"profile_image_url": "null",
			"profile_image_url_https": "https://pbs.twimg.com/profile_images/936652894371119105/YHEozVAg_normal.jpg"
		},
		"3001969357": {
			"id": "3001969357",
			"created_timestamp": "1422556069340",
			"name": "Jordan Brinks",
			"screen_name": "furiouscamper",
			"location": "Boulder, CO",
			"description": "Alter Ego - X PE opinions-are-my-own",
			"url": "https://t.co/SnxaA15ZuY",
			"protected": false,
			"verified": false,
			"followers_count": 23,
			"friends_count": 48,
			"statuses_count": 510,
			"profile_image_url": "null",
			"profile_image_url_https": "https://pbs.twimg.com/profile_images/851526626785480705/cW4WTi7C_normal.jpg"
		}
	}
}

tweet_delete_events

{
    "for_user_id": "930524282358325248",
    "tweet_delete_events": [
{
        "status": {
            "id": "1045405559317569537",
            "user_id": "930524282358325248"
        },
        "timestamp_ms": "1432228155593"
    }
   ]
}

API de Reproducción de Actividad de Cuenta

Enterprise La API de Reproducción de Actividad de Cuenta es una herramienta de recuperación de datos que te permite recuperar eventos de hasta cinco días atrás. Debe utilizarse para recuperar datos en escenarios en los que tu servidor de webhook deja de recibir eventos, ya sea debido a desconexiones que duren más que la ventana de reintentos, o en aquellos escenarios de recuperación ante desastres en los que necesitas unos días para restaurar tu sistema a la normalidad. La API de Reproducción de Actividad de Cuenta se desarrolló para cualquier escenario en el que no puedas ingestar actividades durante un período de tiempo. Entrega actividades al mismo webhook utilizado para la entrega original en tiempo real de las actividades. Este producto es una herramienta de recuperación y no una herramienta de carga histórica (backfill), lo que significa que los eventos solo se reproducirán si se intentó una entrega previa de los mismos. La API de Reproducción de Actividad de Cuenta no puede entregar eventos correspondientes a un período anterior al momento de creación de una suscripción.

Uso de Account Activity Replay API

Si tu cuenta está configurada con la funcionalidad de Replay, puedes realizar solicitudes de manera similar a las solicitudes a Account Activity API. Es importante tener en cuenta que tu solicitud debe especificar un parámetro webhook id para indicar las actividades de qué webhook deseas reproducir. En otras palabras, una solicitud de Replay le pide a Account Activity Replay API que recupere eventos desde una fecha y hora de inicio hasta una fecha y hora de finalización basándose en el webhook id y el application id. Ten en cuenta que se espera la hora en UTC. Estas actividades se entregan a través del webhook registrado asociado con el id a una velocidad de hasta 2.500 eventos por segundo. Ten también en cuenta que solo puede estar en ejecución un trabajo de Replay por webhook a la vez, aunque todas las suscripciones que estuvieron activas durante el intervalo de fecha y hora especificado en ese webhook serán reproducidas. Los eventos se entregan comenzando por el primer (más antiguo) minuto del período de tiempo especificado, continuando de forma cronológica (en la medida de lo posible) hasta que se entrega el último minuto. En ese momento, Replay entregará un evento de finalización del trabajo al webhook. Debido a que trabajamos de forma cronológica al entregar actividades, si hay pocos o ningún resultado coincidente cerca de la hora de inicio, probablemente habrá un período de tiempo antes de que se entreguen los primeros resultados.

Limitaciones

Replay está diseñado como una herramienta para recuperar fácilmente actividades de los últimos cinco días, pero no entregará eventos anteriores al momento en que se creó una suscripción. Por ejemplo, si hace tres días se añadió una nueva suscripción y se ejecutó un trabajo de Replay con una ventana de los cinco días anteriores a hoy, solo se recibirían datos de los tres días en que esta nueva suscripción estuvo activa.

Disponibilidad de datos y tipos

Las actividades de la Account Activity Replay API están disponibles durante cinco días desde el inicio de la solicitud, y los datos nuevos pasan a estar disponibles aproximadamente 10 minutos después de que se crea una actividad determinada. Podrás realizar solicitudes especificando un intervalo de tiempo dentro de esta ventana de cinco días usando los parámetros from_date y to_date en la solicitud. Los eventos que se entregaron originalmente antes de tener acceso a Replay no se pueden reproducir. Por ejemplo, si se habilitó el acceso de tu cuenta a la Account Activity Replay API el 1 de junio de 2019 a las 3:30 p. m. UTC, no podrías usar Replay para recuperar ningún evento anterior a esa fecha y hora. Sigue con la Referencia de la Account Activity Replay API

Introducción a la migración

Retiramos los productos Site Streams, User Streams y la versión beta estándar de Account Activity API - DM Only en 2018. Si habías estado usando esos productos, asegúrate de migrar a la versión premium o enterprise de Account Activity API. **También hemos retirado los endpoints heredados de Mensajes Directos. Si habías estado usando esos endpoints, asegúrate de migrar a los nuevos endpoints de DM o a la versión premium o enterprise de Account Activity API. ** Revisa este anuncio para obtener más información. Estos son los endpoints que se verán afectados por estos cambios:

User Streams
Site Streams
GET direct_messages
GET direct_messages/sent
GET direct_messages/show
POST direct_messages/new
POST direct_messages/destroy

Contamos con nuevos endpoints y servicios que proporcionan un acceso similar y, en el caso de los Mensajes Directos, funcionalidad adicional:

Account Activity API enterprise y premium
GET direct_messages/events/list
GET direct_messages/events/show
POST direct_messages/events/new
POST direct_messages/events/destroy

Para ayudarte a realizar una migración fluida a estos nuevos endpoints y servicios, disponemos de dos guías de migración:

Guía de migración de Account Activity API para quienes pasan de User Streams y Site Streams a nuestro nuevo servicio basado en webhooks
Guía de migración de Mensajes Directos para quienes migran entre endpoints REST de Mensajes Directos

Además, contamos con una serie de vídeos sobre Account Activity API y cómo empezar. Y, por último, tenemos ejemplos de código para ampliar tu comprensión y ayudarte a comenzar rápidamente:

El Account Activity Dashboard es una aplicación web de Node.js de ejemplo con scripts auxiliares para comenzar a usar Account Activity API.
SnowBot es un chatbot de ejemplo que usa Account Activity API y endpoints REST de Mensajes Directos. Está escrito en Ruby, utiliza el framework web Sinatra y se despliega en Heroku.

Guía de migración: migrar de User Streams/Site Streams a Account Activity API

A partir del 23 de agosto de 2018, retiramos tanto Site Streams como User Streams. Asegúrate de migrar a Account Activity API. Revisa este anuncio para obtener más información. Esta guía está diseñada para ayudarte a migrar de las API heredadas de User Streams y Site Streams a su reemplazo, Account Activity API. A continuación encontrarás un resumen de los cambios, una lista de nuevas funcionalidades, así como las diferencias y consideraciones clave para ayudarte con la transición. Para obtener orientación sobre la migración desde endpoints básicos de DM, consulta la guía de migración de Direct Message.

Resumen de los cambios

La API Account Activity te enviará eventos de cuentas autenticadas y suscritas a través de webhooks, en lugar de mediante una conexión de streaming como en User Streams y Site Streams.

APIs en desuso

GET user GET site (incluidos los streams de control: GET site/c/:stream_id, GET site/c/:stream_id/info.json, GET site/c/:stream_id/friends/ids.json, POST site/c/:stream_id/add_user.json, POST /site/c/:stream_id/remove_user.json)

APIs de sustitución

Enterprise Account Activity API - Todas las actividades

Diferencias y consideraciones de migración

Formato de la API: La nueva Account Activity API funciona de manera diferente a User Streams y Site Streams. Deberás modificar tu aplicación web para recibir datos mediante webhooks. Puedes encontrar más información sobre webhooks aquí. Datos disponibles: Otra diferencia clave que notarás se refiere a los datos que se entregan. X ya no enviará eventos de personas a las que sigues en X (es decir, tu cronología de inicio). Este fue un cambio intencional y no es algo que tengamos previsto modificar en el futuro. Fiabilidad: A diferencia del streaming, los webhooks permiten la confirmación de la entrega y ofrecen opciones para reintentar actividades enviadas mediante solicitudes POST que no lleguen a la URL del webhook. Esto proporciona una mayor garantía de que la aplicación está recibiendo todas las actividades pertinentes, incluso si hay breves desconexiones o períodos de inactividad.

Nuevas funcionalidades

La Account Activity API ofrece muchas funcionalidades nuevas, en particular que ahora los datos se entregan mediante webhooks en lugar de streaming. Los webhooks ofrecen muchas ventajas en comparación con el streaming, pero las más destacadas son la velocidad y la fiabilidad. La API te enviará datos en forma de eventos JSON a medida que estén disponibles y ya no necesitarás mantener una conexión activa ni realizar sondeos al endpoint. Esto reduce la necesidad de funcionalidades de redundancia y aumenta la eficiencia en general. Puedes encontrar más información sobre webhooks en la documentación técnica.

Gestión de suscripciones de usuario

La API de actividad de cuentas permite múltiples suscripciones para un solo webhook registrado. Esto permite que las actividades de suscripción de varios usuarios se entreguen en el mismo destino, de forma similar a la arquitectura de Site Streams, pero mediante webhooks. Esto significa que puedes hacer un seguimiento de las suscripciones, en relación con tus límites de suscripción, de forma independiente de la conexión del webhook. Esto también permite escalar desde una o unas pocas suscripciones hasta miles de suscripciones para un solo webhook.

Cómo migrar

Sigue los pasos a continuación para migrar fácilmente de la Site Streams API a la Account Activity API

Paso 1: Elige un paquete Según cómo estés operando actualmente con User Streams o Site Streams, deberías considerar pasar a la versión enterprise o premium de la Account Activity API. Ten en cuenta el número de aplicaciones o usuarios autorizados que estás gestionando actualmente y ajusta la escala de acuerdo con el volumen y la confiabilidad necesarios. Al decidir sobre el paquete que mejor se adapte a tus necesidades, algunos aspectos que vale la pena considerar son:

Número de webhooks necesarios
Suscripciones/usuarios autorizados actuales/proyectados gestionados en tu aplicación
Número actual de aplicaciones cliente de X
El nivel de soporte que prefieres por parte de X (soporte mediante foro o soporte enterprise gestionado 1:1)
El precio de cada paquete

Paso 2: Verifica la configuración de tu app de X en la Consola de desarrollador La app de X que se utiliza actualmente para User Streams o Site Streams aparecerá en la lista para el usuario propietario dentro de la Consola de desarrollador. Esta app de X también puede usarse para Account Activity API para conservar los usuarios autorizados de esa aplicación. También se puede crear una nueva app y los usuarios pueden volver a autorizar esta nueva app si se desea. Si estás creando una nueva app en nombre de una empresa, se recomienda que crees la app con una cuenta corporativa de X @handle.

Habilita “Read, Write and Access direct messages” en la pestaña de permissions de la página de tu app de X. *Ten en cuenta que cambiar estas opciones no es retroactivo; cualquier usuario autorizado conservará la configuración de autorización del momento en que fue autorizado. Si un usuario aún no te ha otorgado acceso de lectura, escritura y mensajes directos, deberás hacer que ese usuario vuelva a autorizar tu aplicación.
Si no estás familiarizado con X Sign-in y cómo funcionan los contextos de usuario con la X API, revisa Obtaining Access Tokens.
Genera tokens de acceso para el propietario de la app de X en la parte inferior de la pestaña “Keys and Tokens”. En esta misma pestaña, toma nota de tu Consumer Key, Consumer Secret, Access Token y Access Token Secret. Los necesitarás para usar la API.
Genera un Bearer Token usando tu Consumer Key y Consumer Secret para métodos de la API en modo application-only.

Paso 3: Configura tus webhooks

Crea una aplicación web con un endpoint para usar como tu webhook y recibir eventos (por ejemplo, https://your_domain.com/webhook/twitter o https://webhooks.your_domain.com).
Usa tu Consumer Key, Consumer Secret, Access Token y Access Token Secret al crear tu webhook. Ten en cuenta que tu endpoint debe devolver una respuesta JSON con un response_token que sea un hash HMAC SHA-256 codificado en base64 creado a partir del crc_token y el Consumer Secret de tu app.
Revisa la documentación de Securing Webhooks, prestando especial atención a los requisitos de Challenge Response Check (CRC).
Asegúrate de que tu webhook admita solicitudes POST para eventos entrantes y solicitudes GET para el CRC.
Asegúrate de que tu webhook tenga baja latencia (<3 segundos para responder a solicitudes POST)

Paso 4: Valida la configuración de tu webhook

Las Webhook APIs protegerán tus webhooks de dos maneras:

- Requerir comprobaciones de desafío-respuesta para validar que el propietario del webhook es el propietario de la aplicación web. - Un encabezado de firma en cada solicitud POST para que tu aplicación web valide el origen.

Para verificar que eres tanto el propietario de la aplicación web como de la URL del webhook, X realizará un Challenge Response Check (CRC), que no debe confundirse con una comprobación de redundancia cíclica.
Se enviará una solicitud GET con un parámetro llamado crc_token a la URL de tu webhook. Tu endpoint debe devolver una respuesta JSON con un response_token que sea un hash HMAC SHA-256 codificado en base64 creado a partir del crc_token y el Consumer Secret de tu app.
Se debe esperar que el crc_token cambie en cada solicitud de CRC entrante. El crc_token debe usarse como mensaje en el cálculo, donde tu Consumer Secret es la clave.
En caso de que la respuesta sea inválida, se dejarán de enviar eventos al webhook registrado.

Paso 5: Crea suscripciones para cada usuario autorizado de User Streams o Site Streams Conversión desde User Streams a la Account Activity API:

Genera una lista de tus suscripciones de usuario actuales en User Streams
Configura tus nuevas suscripciones de Account Activity API mediante la solicitud: POST account_activity/all/:env_name/subscriptions
Confirma tus suscripciones de Account Activity API mediante la solicitud: _GET account_activity/all/:env_name/subscriptions/list _

Conversión a Account Activity API desde Site Streams (usando control streams):

Genera una lista de tus suscripciones actuales en Site Streams mediante la solicitud: GET /1.1/site/c/:stream_id/info.json
Configura tus nuevas suscripciones de Account Activity API mediante la solicitud: POST account_activity/all/:env_name/subscriptions
Confirma tus suscripciones de Account Activity API mediante la solicitud: _GET account_activity/all/:env_name/subscriptions/list _

Registro de un webhook y creación de suscripciones (sin migrar desde Site Streams o User Streams)

Registra la URL de tu webhook con tu App usando POST webhooks y recibe un webhook_id.
Usa el webhook_id devuelto para agregar suscripciones de usuario con POST webhooks/:webhook_id/subscriptions/all.

El panel de Account Activity (aplicación de ejemplo de Account Activity API)

Hemos creado una aplicación de ejemplo para que probar Account Activity API sea un poco más rápido:

Descarga la aplicación de ejemplo Account Activity Dashboard aquí (usa Node.js)
Sigue las instrucciones del README para instalar e iniciar la aplicación
Una vez que la aplicación se haya iniciado, puedes usar la interfaz de usuario para configurar fácilmente tu webhook y crear una nueva suscripción

Actividades disponibles

Tipo de mensaje	Detalles
tweet_create_events	Carga útil del estado de la Publicación cuando se realiza cualquiera de las siguientes acciones por parte del usuario de la suscripción o dirigidas a él: Publicaciones, Retweets, respuestas, menciones @, Tweets citados
favorite_events	Evento de favorito (like) con el usuario y el objetivo.
follow_events	Evento de seguir con el usuario y el objetivo.
block_events	Evento de bloqueo con el usuario y el objetivo.
mute_events	Evento de silenciar con el usuario y el objetivo.
direct_message_events	Evento de mensaje directo con el usuario y el objetivo.
direct_message_indicate_typing_events	Evento de escritura en mensaje directo con el usuario y el objetivo.
direct_message_mark_read_events	Evento de lectura de mensaje directo con el usuario y el objetivo.

Tipos de mensajes de streaming en desuso


Blank lines	Las líneas en blanco ya no se entregarán en Account Activity API, ya que se utilizaban como mensajes de mantenimiento de la conexión en User Streams y Site Streams.
Limit notices	Los avisos de límite ya no se enviarán al webhook correspondiente. En su lugar, los usuarios pueden llamar a la API para obtener el uso actual de los identificadores disponibles. Esto se incluirá en la Consola de desarrollador en algún momento en el futuro.
Disconnect messages	Los avisos de desconexión ya no serán necesarios, ya que los webhooks no dependen de una conexión activa.
Stall warnings	Las advertencias de bloqueo ya no serán necesarias, ya que los webhooks no dependen de una conexión activa capaz de manejar grandes cantidades de mensajes entrantes.
Friends list	Las listas de amigos ya no se enviarán de forma proactiva. Ahora habrá un endpoint REST para obtener esta información.

Tipos de eventos obsoletos


Descripción	Nombre del evento	Origen	Destino	Objeto de destino
El usuario elimina una publicación	delete	Usuario actual	Usuario actual	Publicación
Un usuario seguido elimina una publicación	delete	Usuario seguido	Usuario seguido	Publicación
El usuario quita de favoritos una publicación	unfavorite	Usuario actual	Autor de la publicación	Publicación
Se quita de favoritos la publicación de un usuario	unfavorite	Usuario que quita de favoritos	Usuario actual	Publicación
El usuario deja de seguir a alguien	unfollow	Usuario actual	Usuario seguido	Null
El usuario crea una lista	list_created	Usuario actual	Usuario actual	Lista
El usuario elimina una lista	list_destroyed	Usuario actual	Usuario actual	Lista
El usuario edita una lista	list_updated	Usuario actual	Usuario actual	Lista
El usuario agrega a alguien a una lista	list_member_added	Usuario actual	Usuario agregado	Lista
El usuario es agregado a una lista	list_member_added	Usuario que agrega	Usuario actual	Lista
El usuario quita a alguien de una lista	list_member_removed	Usuario actual	Usuario eliminado	Lista
El usuario es quitado de una lista	list_member_removed	Usuario que elimina	Usuario actual	Lista
El usuario se suscribe a una lista	list_user_subscribed	Usuario actual	Propietario de la lista	Lista
Se suscriben a la lista de un usuario	list_user_subscribed	Usuario que se suscribe	Usuario actual	Lista
El usuario cancela la suscripción a una lista	list_user_unsubscribed	Usuario actual	Propietario de la lista	Lista
Se cancela la suscripción a la lista de un usuario	list_user_unsubscribed	Usuario que cancela la suscripción	Usuario actual	Lista
El usuario actualiza su perfil	user_update	Usuario actual	Usuario actual	Null
El usuario actualiza el estado de protección de su cuenta	user_update	Usuario actual	Usuario actual	Null

Guía de migración de Mensajes Directos

El 17 de septiembre de 2018 retiramos los endpoints heredados de Mensajes Directos. Si estabas utilizando esos endpoints, asegúrate de migrar a los nuevos endpoints de Mensajes Directos o a la Account Activity API. Consulta este anuncio para obtener más información. Esta guía está diseñada para ayudarte a migrar desde las APIs REST heredadas de Mensajes Directos a sus reemplazos mejorados, que han salido de la fase beta. A continuación encontrarás un resumen de los cambios, una lista de nuevas funciones y las diferencias y consideraciones clave para facilitar la transición. Los nuevos endpoints de Mensajes Directos ya están disponibles para todos los desarrolladores. Para obtener orientación sobre cómo migrar desde User Streams o Site Streams, consulta la guía de migración a Account Activity API.

Resumen de cambios
Nuevas funciones
Envío de Mensajes Directos
Recepción de Mensajes Directos
Eliminación de Mensajes Directos

Resumen de los cambios

Si todavía usas los siguientes endpoints de MD, deberás migrar a los endpoints más recientes.

Endpoint en desuso	Nueva alternativa de migración
POST direct_messages/new	POST direct_messages/events/new
GET direct_messages/show	GET direct_messages/events/show
GET direct_messages	GET direct_messages/events/list
GET direct_messages/sent	GET direct_messages/events/list
POST direct_messages/destroy	DELETE direct_messages/events/destroy

Nuevas funciones

Los nuevos endpoints de la API de Mensajes Directos incorporan varias funcionalidades nuevas y ofrecen un acceso mejorado a Mensajes Directos anteriores. Las nuevas funciones incluyen:

Compatibilidad con archivos multimedia adjuntos (imagen, GIF y video).
Posibilidad de solicitar a los usuarios respuestas estructuradas con una lista de opciones predefinida.
Hasta 30 días de acceso a Mensajes Directos anteriores.

Para ver la lista completa de las nuevas funciones de Mensajes Directos y de los nuevos endpoints de la API, consulta la documentación técnica.

Diferencias y consideraciones de migración

Los nuevos endpoints de la API se comportan de manera muy diferente a los anteriores. Simplemente actualizar las URL de los endpoints dará lugar a errores en tu aplicación. Ten en cuenta lo siguiente al actualizar tu aplicación para la migración.

Nuevo objeto de Mensaje Directo

Lo primero que probablemente notarás es la nueva estructura de objeto de los Mensajes Directos. Esta nueva estructura de objeto Message Create se ha introducido para admitir nuevas funcionalidades como Quick Replies y Attachments. El nuevo objeto también contiene un objeto de usuario más pequeño y condensado. Será necesario actualizar tu aplicación para tener en cuenta esta nueva estructura de objeto al analizarlo y, potencialmente, en los modelos de datos o en el almacenamiento. Para obtener descripciones de cada propiedad, consulta la documentación completa sobre el Message Create Object. Ejemplo de objeto Message Create

{
      "type": "message_create",
      "id": "1234858592",
      "created_timestamp": "1392078023603",
      "initiated_via": {
        "tweet_id": "123456",
        "welcome_message_id": "456789"
      },
      "message_create": {
        "target": {
          "recipient_id": "1234858592"
        },
        "sender_id": "3805104374",
        "source_app_id": "268278",
        "message_data": {
          "text": "Blue Bird",
          "entities": {
            "hashtags": [],
            "symbols": [],
            "urls": [],
            "user_mentions": [],
          },
          "quick_reply_response": {
            "type": "options",
            "metadata": "external_id_2"
          },
          "attachment": {
            "type": "media",
            "media": {
             ...
            }
          }
        }
      }

Resumen

Estructura de objeto de Mensaje Directo completamente nueva.
Objeto de usuario simplificado.
Nueva información disponible (respuestas a respuestas rápidas, archivos adjuntos, etc.).

Envío de Mensajes Directos

POST direct_messages/events/new es un sustituto directo para enviar Mensajes Directos. La diferencia más significativa con este endpoint es que ahora toda la información se envía como JSON en el cuerpo de la solicitud POST en lugar de como parámetros POST individuales. Ejemplo de solicitud Twurl

twurl -A 'Content-type: application/json' -X POST /1.1/direct\_messages/events/new.json -d '{"event": {"type": "message\_create", "message\_create": {"target": {"recipient\_id": "4534871"}, "message_data": {"text": "Hello World!"}}}}'

Ten en cuenta en la solicitud anterior que el content-type está configurado como application/json en lugar de application/x-www-form-urlencoded. Además, si estás construyendo la firma OAuth 1.0a, ten en cuenta que el cuerpo JSON no se incluye en la generación de la firma. La mayoría de las bibliotecas de OAuth ya contemplan esto. Si estás usando twurl, asegúrate de usar al menos la versión 0.9.3.

Resumen

El mensaje se define en el cuerpo de la solicitud POST en formato JSON
El encabezado Content-Type debe establecerse en application/json
El cuerpo JSON no se incluye en la generación de la firma de OAuth

Recuperar Mensajes Directos

La recuperación de Mensajes Directos anteriores ahora se realiza con un único endpoint de API: GET direct_messages/events/list. La diferencia importante con este nuevo endpoint es que ahora devuelve tanto los mensajes enviados como los recibidos en orden cronológico inverso. Esto puede facilitar la reconstrucción de una conversación. Sin embargo, si solo buscas mensajes enviados o recibidos, deberás posprocesar la respuesta consultando la propiedad sender_id. La paginación ahora se basa en un valor de cursor en lugar del id de un Mensaje Directo. En cada respuesta se devuelve una propiedad cursor. GET direct_messages/events/list devolverá hasta 30 días de mensajes anteriores, independientemente de cuántos mensajes existan dentro de esos 30 días. Cuando no se devuelve un cursor, no hay más mensajes que recuperar. El método para acceder a Mensajes Directos individuales con GET direct_messages/events/show sigue siendo el mismo, aunque el objeto de Mensaje Directo devuelto tiene una estructura diferente, como se describió anteriormente. Por último, el acceso en tiempo real a Mensajes Directos ahora se realizará mediante webhook con la Account Activity API. Para obtener orientación sobre la migración desde User Streams o Site Streams, consulta la guía de migración de Account Activity API para obtener más información.

Resumen

Los mensajes enviados y recibidos ahora se devuelven en el mismo endpoint.
Se devuelven mensajes de hasta 30 días de antigüedad.
Paginación basada en cursores.
Acceso en tiempo real a Mensajes Directos mediante webhook.

Eliminación de Mensajes Directos

Ahora se pueden eliminar Mensajes Directos con DELETE direct_messages/events/destroy. La interfaz es prácticamente la misma y requiere el id del mensaje que se va a eliminar. La diferencia clave es que ahora el endpoint requiere una solicitud DELETE en lugar de una solicitud POST. La forma en que los Mensajes Directos eliminados se reflejan en los clientes oficiales de X sigue siendo la misma. Los Mensajes Directos solo se eliminan de la interfaz del usuario cuyo contexto se utiliza. Otros miembros de la conversación aún pueden acceder a los Mensajes Directos.

Resumen

Para eliminar un mensaje directo se requiere el id.
El nuevo endpoint requiere una solicitud DELETE.
La forma en que los mensajes directos eliminados se reflejan en los clientes oficiales de X permanece sin cambios.

**¿Tienes preguntas sobre cómo migrar a los nuevos endpoints de mensajes directos? **Publica tu pregunta en el foro de la comunidad de desarrolladores en devcommunity.com.

Preguntas frecuentes

General

¿Cuáles son las ventajas de usar la Account Activity API? La Account Activity API usa webhooks, lo que significa que, a diferencia de las APIs de streaming, no necesitas mantener una conexión abierta para que podamos enviarte información. Los webhooks también son diferentes de las APIs REST porque no tienes que hacernos cientos de solicitudes cada 15 minutos para obtener los datos que te interesan. Esto aumenta la eficiencia entre un usuario y tu app, ya que entrega los datos cuando ocurren. La Account Activity API tiene varias ventajas:

Velocidad: entregamos los datos a la velocidad de X.
Simplicidad: entregamos todos los eventos de una cuenta a través de una única conexión de webhook. Las actividades entregadas en la API incluyen Publicaciones, @menciones, respuestas, Retweets, Quote Tweets, Retweets de Quote Tweets, favoritos, mensajes directos enviados, mensajes directos recibidos, follows, blocks y mutes.
Escalabilidad: recibes todas las actividades de una cuenta que administras sin estar restringido por ningún límite de tasa ni topes de eventos.

La Account Activity API está disponible como una oferta de sandbox premium, premium de pago y enterprise, por lo que puedes escalar según necesites más cuentas para funciones de responsabilidad o funcionalidad adicional. Para comenzar, descarga fragmentos de código de ejemplo desde GitHub. ¿Cómo identifico qué nivel de producto es mejor para mí? Lee nuestra página de Account Activity API Overview para obtener más información sobre las diferencias entre las opciones Premium y la opción Enterprise. ¿Cuál es la diferencia entre un entorno Premium y un webhook Enterprise? No hay ninguna diferencia. Cada entorno Premium tendrá su propio webhook_id. Necesito entornos de desarrollo, staging y producción para Account Activity API, ¿es esto posible? ¡Sí! Con los niveles de pago de Account Activity API (Premium de pago y Enterprise), es posible registrar varias URL de webhook y administrar las suscripciones por separado para cada una mediante los métodos de la API. Además, se pueden agregar varias apps cliente a una allowlist para mantener la autorización de tus usuarios autorizados actuales. ¿Tienen alguna guía paso a paso sobre cómo configurar la Account Activity API? De hecho, ¡sí tenemos!

Si recién estás comenzando, te recomendamos que visites nuestra guía Getting started with webhooks
Sigue nuestros scripts proporcionados por X Dev:
- Account Activity API dashboard, una aplicación web Node que muestra eventos de webhook.
- El chatbot SnowBot, una aplicación web Ruby creada sobre las Account Activity y Direct Message APIs. Este código base incluye un script para ayudar a configurar los webhooks de Account Activity API.

¿Hay alguna forma de recuperar datos si nuestro sistema deja de funcionar durante un período de tiempo? Con los niveles de pago de Account Activity API (Premium de pago y Enterprise), nuestro sistema reintentará enviarte las actividades varias veces durante un período de cuatro horas. Si tu sistema no responde dentro de ese período de cuatro horas, la actividad se perderá y tendrás que usar otros endpoints REST para recuperar datos dentro de un plazo de 7 días. Te sugerimos que uses tus distintos webhooks, o entornos, como herramienta de redundancia, como la Account Activity Replay API, para asegurarte de no perder ninguna actividad si uno de tus sistemas deja de funcionar. ¿Qué autenticación tengo que usar con la Account Activity API? Los métodos de autorización requeridos para Account Activity API se describen por método en las páginas de referencia de la API. Si recién estás comenzando con la autenticación de X, te recomendamos que leas esta sección. ¿Qué es una comprobación de desafío-respuesta (CRC)? La verificación de respuesta al desafío de la Account Activity API es una función de seguridad implementada para garantizar que las actividades de la Account Activity API se envíen al desarrollador adecuado. También puede ser utilizada por los desarrolladores para asegurarse de que los datos que están recibiendo provienen de X. X enviará automáticamente un CRC a tu URL de webhook una vez cada 24 horas, a partir de la última vez que se validó la URL del webhook. Tu sistema debe responder con una respuesta válida en un plazo de 3 segundos para seguir validado. Visita la página Protección de webhooks para obtener más detalles. ¿Hay algo que invalidaría inmediatamente mi URL de webhook? Si ocurre una de las siguientes situaciones, marcaremos inmediatamente tu webhook como inválido:

El servidor responde a un CRC con un token incorrecto. En este caso, nuestro sistema no reintentará enviarte la actividad.
La URL del webhook tiene configurado un certificado incorrecto. En este caso, nuestro sistema no reintentará enviarte la actividad.
Tu servidor devuelve un código de respuesta que no es 2XX, 4XXX ni 5XXX.
Especificas el uso de gzip sin enviarlo realmente.
No especificas el uso de gzip, pero en realidad lo envías en la respuesta.

¿Recibiré actividades duplicadas si estoy suscrito a usuarios que interactúan entre sí? Sí. Si tu aplicación web tiene suscripciones activas para el Usuario A y el Usuario B, y el Usuario A menciona al Usuario B en una Publicación, se enviarán dos actividades POST al webhook registrado. Cada actividad tendrá un indicador “for_user_id” para mostrar a qué suscripción pertenece la actividad. **Cuando creo una suscripción a mi webhook, ¿puedo reemplazar la parte /all/ del siguiente endpoint con otros objetos de datos de Account Activity para limitar las actividades que entrega la API? **POST https://api.x.com/1.1/account_activity/all/:env_name/subscriptions.json No, esto no es posible. En la situación actual, solo tenemos disponible el producto /all/. **¿Hay alguna forma de usar la Account Activity API sin solicitar permisos de Mensajes Directos a los usuarios? ** En este momento, se requieren permisos de Mensajes Directos porque no existe ninguna forma de “filtrar” las actividades de Mensajes Directos para esta API. ¿Existe una versión sandbox de la Account Activity API? Sí, ofrecemos una opción de sandbox para pruebas. Nuestra opción de sandbox está limitada a un único webhook con un máximo de 15 suscripciones. Puedes leer más sobre la opción de sandbox en nuestra documentación. **¿Es posible usar la Account Activity API para obtener Retweets de Publicaciones que mencionan a usuarios suscritos? ** Lamentablemente, esto no forma parte de las actividades entregadas con esta API. Para esto, sugerimos usar la Streaming API. ¿Cuáles son los posibles tipos de actividad que están representados por un tweet_create_event? Se enviará una carga útil de tweet_create_event: Si el usuario suscrito realiza cualquiera de las siguientes acciones:

Crea una Publicación
Hace Retweet
Responde a una Publicación

Si otro usuario:

@menciona* al usuario suscrito
Cita un Tweet creado por el usuario suscrito

*Nota: La Account Activity API solo entrega eventos cuando el usuario suscrito recibiría una notificación de X y podría ver el evento públicamente. Esto significa que, si la cuenta mencionada (@userA) sigue a la cuenta protegida (@userB), entonces UserA recibirá una notificación de que UserB lo mencionó. Si UserA no sigue a UserB (y no ha sido aprobado por UserB), UserA no recibirá una notificación, y por lo tanto no se enviaría un tweet_create_event a través de AAA si @userA tuviera una suscripción. Si un usuario bloqueado menciona a mi usuario suscrito, ¿cómo puedo identificarlo? Verás un campo booleano user_has_blocked en el nivel superior de la respuesta JSON, establecido en “true” o “false”. Este campo solo se expondrá en menciones en Publicaciones. Enterprise ¿Cómo puedo añadir mi App a una allowlist o comprobar si mi App ya está en la allowlist? Para gestionar las X apps que has añadido a una allowlist para el acceso mediante las Enterprise APIs, ponte en contacto con tu account manager y facilítale tu app ID. Puedes encontrar tu app ID yendo a la página “Apps” en la Consola de desarrollador. Si tengo acceso a tres webhooks, ¿puedo usar tres webhooks para cada una de las apps que he registrado para uso empresarial? El límite de webhooks se establece a nivel de cuenta, no a nivel de app. Si tienes acceso a tres webhooks y dos apps registradas para uso empresarial, puedes usar dos webhooks en una app y el tercero en la otra app, pero no tres en cada app. ¿Puedo especificar qué tipos de eventos se volverán a entregar usando la Account Activity Replay API? Los tipos de eventos a reproducir no se pueden especificar. Se volverán a reproducir todos los eventos entregados durante el intervalo de fecha y hora especificado. ¿Habrá reintentos si mi aplicación no logra procesar un evento de la Account Activity Replay API? No, no habrá reintentos. Si una aplicación no logra procesar un evento enviado por la Account Activity Replay API, se puede enviar otro Replay job para el mismo período de tiempo para intentar la reentrega de cualquier Replay event que se haya perdido. ¿Qué debo hacer cuando recibo un evento de finalización con éxito parcial (partial success)? Sugerimos que tomes nota de las marcas de tiempo (timestamps) de los eventos que se recibieron y solicites otro Replay job para los eventos que faltaron. ¿Cuántos Replay jobs de Account Activity Replay API puedo tener en ejecución al mismo tiempo? Solo puede estar en ejecución un Replay job de Account Activity Replay API por webhook a la vez. ¿Cómo puedo diferenciar los eventos de Account Activity Replay API de los eventos de producción en tiempo real a medida que se entregan a mi webhook? Dado que la Account Activity Replay API siempre entregará eventos del pasado, los eventos se pueden diferenciar de los eventos de producción en tiempo real en función de la marca de tiempo del evento. ¿Con qué rapidez puedo empezar a usar la Account Activity Replay API para volver a entregar una actividad que mi aplicación descartó o se perdió? Una actividad pasa a estar disponible para su reentrega aproximadamente 10 minutos después de que se creó.

Guía para solucionar errores

Code 32

Este error generalmente significa que algo está mal definido en la solicitud, los encabezados, la autorización o la URL que estás especificando. Este no es un error de la Account Activity API, es un error de autorización y X no está recibiendo la configuración correcta de OAuth ni la URL adecuada.

Enterprise - Asegúrate de que las consumer keys y los access tokens que estás utilizando pertenezcan a una App de X que haya sido registrada para el uso de productos Enterprise. Si no tienes tus consumer keys y access tokens, o necesitas agregar tu App de X a la allowlist, ponte en contacto con tu account manager.
Si te autenticas con contexto de usuario, asegúrate de haber autorizado correctamente tu solicitud con los valores correctos para oauth nonce, oauth_signature y oauth_timestamp.
Asegúrate de que tus access tokens tengan el nivel de permisos adecuado.
- En la pestaña ‘Keys and tokens’ del app dashboard, asegúrate de que tus access tokens tengan el nivel de permisos ‘Read, write, and direct messages’ permission level.
- Si el nivel de permisos de los tokens está configurado en algo menor que esto, ve a la pestaña ‘Permissions’, ajusta el permiso de acceso a ‘Read, write, and direct messages’ y luego vuelve a generar tus access tokens y secret desde la pestaña ‘Keys and tokens’.
Asegúrate de que tu URL esté formada correctamente.
- Ten en cuenta que :env_name distingue entre mayúsculas y minúsculas.

Código 200 - Prohibido

Premium - Asegúrate de que tienes una cuenta de desarrollador aprobada antes de intentar realizar una solicitud a la API. También debes usar el :env_name correcto en la solicitud, que puedes configurar en la página de entornos de desarrollo.
Enterprise - Asegúrate de que tu gestor de cuenta te haya habilitado el acceso a la Account Activity API.
Asegúrate de haber configurado correctamente tu URI. Este error puede producirse si has introducido una URI incorrecta en tu solicitud.

Código 214 - La URL del webhook no cumple con los requisitos.

Asegúrate de usar HTTPS.
La URL de tu webhook podría estar mal formada.
Obtén más información sobre cómo configurar la URL de tu webhook en la sección Develop webhook consumer app de la página Getting started with webhooks.

Código 214 - Alta latencia en la solicitud GET de CRC. Tu webhook debe responder en menos de 3 segundos.

Esto significa que tu servidor es lento. Asegúrate de responder al CRC en un plazo máximo de 3 segundos.

Código 214 - Código de respuesta distinto de 200 durante la solicitud GET de CRC (es decir, 404, 500, etc.).

Tu servidor está caído. Asegúrate de que tu servidor esté funcionando correctamente.

Código 214 - Ya se han creado demasiados recursos.

Enterprise - Ya has usado todos tus webhooks. Utiliza el endpoint GET webhooks con cada una de tus Apps registradas para identificar en qué Apps están configurados tus webhooks.

Código 261 - La aplicación no puede realizar acciones de escritura.

La App que estás utilizando con la API no tiene configurado el nivel de permiso adecuado para su access token y access token secret. Dirígete a la pestaña «Keys and tokens» en el panel de X apps y comprueba los niveles de permiso asignados a tu access token y access token secret. Si está configurado en cualquier valor distinto de «Read, write and Direct Messages», tendrás que ajustar la configuración en la pestaña «Permission» y regenerar tu access token y access token secret para aplicar la nueva configuración.
Como alternativa, es posible que estés intentando registrar un webhook utilizando autenticación solo de App, lo cual no es compatible. Autentícate con contexto de usuario tal como se indica en las secciones de Referencia de la API para registrar un webhook para la Enterprise Account Activity API.

Índice de referencia de la Account Activity API


Purpose	Enterprise
Registra una URL de webhook / genera un webhook_id	POST webhooks
Devuelve todas las URL de webhook y sus estados	GET webhooks
Activa manualmente una comprobación de respuesta al desafío	PUT webhooks/:webhook_id
Suscribe una aplicación a los eventos de una cuenta	POST webhooks/:webhook_id/subscriptions/all
Devuelve el número de suscripciones activas actualmente	GET subscriptions/count
Comprueba si un webhook está suscrito a una cuenta	GET webhooks/:webhook_id/subscriptions/all
Devuelve una lista de suscripciones activas actualmente	GET webhooks/:webhook_id/subscriptions/all/list
Elimina el webhook	DELETE webhooks/:webhook_id
Desactiva una suscripción usando OAuth de 3 patas (EN DESUSO)	DELETE webhooks/:webhook_id/subscriptions/all
Desactiva una suscripción usando OAuth solo para aplicaciones	DELETE webhooks/:webhook_id/subscriptions/:user_id/all.json
Reenvía las actividades a un webhook	POST replay/webhooks/:webhook_id/subscriptions/all

API de actividad de cuentas empresariales

POST account_activity/webhooks

Registra una nueva URL de webhook para el contexto de la aplicación especificado. La URL se validará mediante una solicitud CRC antes de guardarse. En caso de que la validación falle, se devolverá un mensaje de error detallado al solicitante. El número de webhooks permitidos lo determina el paquete de facturación.

URL del recurso

https://api.x.com/1.1/account_activity/webhooks.json

Información del recurso


Formato de la respuesta	JSON
Requiere autenticación	Sí (contexto de usuario: todos los tokens de consumidor y de acceso)
Sujeto a límite de frecuencia	Sí
Solicitudes / ventana de 15 minutos (autenticación de usuario)	15
Compatibilidad con edición de Tweets	Todos los objetos de Tweet incluirán metadatos de edición de Tweet que describen el historial de ediciones del Tweet. Consulta la página “Aspectos fundamentales de las ediciones de Tweet” para obtener más detalles.

Parámetros


url (obligatorio)	URL codificada del endpoint de callback.

Ejemplo de solicitud

$ curl —request POST —url ‘https://api.x.com/1.1/account_activity/webhooks.json?url=https%3A%2F%2Fyour_domain.com%2Fwebhooks%2Ftwitter%2F0' —header ‘authorization: OAuth oauth_consumer_key=“CONSUMER_KEY”, oauth_nonce=“GENERATED”, oauth_signature=“GENERATED”, oauth_signature_method=“HMAC-SHA1”, oauth_timestamp=“GENERATED”, oauth_token=“ACCESS_TOKEN”, oauth_version=“1.0“‘

Respuestas HTTP

Código HTTP	Mensaje
200	La URL del webhook está registrada en la aplicación proporcionada
403	Hay un error en tu solicitud. Consulta la sección de mensajes de error a continuación.

Ejemplo de respuesta: éxito

_HTTP 200_

    {
      "id": "1234567890",
      "url": "https://your_domain.com/webhook/twitter/0",
      "valid": true,
      "created_at": "2016-06-02T23:54:02Z"
    }

Mensajes de error

Código	Mensaje
214	La URL del webhook no cumple los requisitos.
214	Ya se han creado demasiados recursos.
214	La URL del webhook no cumple los requisitos. Token CRC o formato de respuesta JSON no válidos.
214	Alta latencia en la solicitud GET de CRC. El webhook debe responder en menos de 3 segundos.
214	Código de respuesta distinto de 200 durante la solicitud GET de CRC (por ejemplo, 404, 500, etc.).

HTTP 403

    {
      "errors": [
        {
          "code": 214,
          "message": "Too many resources already created."
        }
      ]
    }

GET account_activity/webhooks

Devuelve todas las URL y sus estados para la aplicación indicada. Marcamos una URL como no válida si falla la comprobación diaria de validación. Para volver a habilitar la URL, llama al endpoint de actualización.

URL del recurso

https://api.x.com/1.1/account_activity/webhooks.json

Información del recurso


Formato de respuesta	JSON
Requiere autenticación	Sí (solo App - Bearer Token)
Con límite de uso	Sí
Solicitudes / ventana de 15 minutos (autenticación de App)	15

Ejemplo de solicitud

    $ curl --request GET
     --url https://api.x.com/1.1/account_activity/webhooks.json
     --header 'authorization: Bearer TOKEN'

Ejemplo de respuesta

HTTP 200 OK

    [
      {
        "id": "1234567890",
        "url": "https://your_domain.com/webhook/twitter/0",
        "valid": true,
        "created_at": "2016-06-02T23:54:02Z"
      }
      {
        "id": "2468013579",
        "url": "https://your_domain2.com/webhook/twitter/0",
        "valid": true,
        "created_at": "2016-06-04T22:31:29Z"
      }
    ]

Mensajes de error

Código	Mensaje
99	No tienes acceso a este recurso.

PUT account_activity/webhooks/:webhook_id

Activa la comprobación de desafío-respuesta (CRC) para la URL del webhook especificado. Si la comprobación se realiza correctamente, devuelve un 204 y vuelve a habilitar el webhook estableciendo su estado en valid.

URL del recurso

https://api.x.com/1.1/account_activity/webhooks/:webhook_id.json

Información del recurso


Formato de respuesta	JSON
Requiere autenticación	Sí (contexto de usuario: todos los tokens de consumidor y de acceso)
Con límite de frecuencia	Sí
Solicitudes / ventana de 15 minutos (autenticación de usuario)	15

Parámetros


webhook_id (required)	ID del webhook. Se define en la ruta del recurso.

Ejemplo de solicitud

    $ curl --request PUT
     --url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID.json
     --header 'authorization: OAuth oauth_consumer_key="CONSUMER_KEY", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="ACCESS_TOKEN", oauth_version="1.0"'

Respuesta

HTTP 204 OK

{ }

Mensajes de error

Código	Mensaje
34	El webhook no existe o está asociado con una aplicación de X distinta.
214	La URL del webhook no cumple los requisitos.
214	La URL del webhook no cumple los requisitos. Token CRC o formato de respuesta JSON no válidos.
214	Alta latencia en la solicitud GET de CRC. Tu webhook debe responder en menos de 3 segundos.
214	Código de respuesta distinto de 200 durante la solicitud GET de CRC (por ejemplo, 404, 500, etc.).

POST account_activity/webhooks/:webhook_id/subscriptions/all

Suscribe la aplicación proporcionada a todos los eventos del contexto de usuario proporcionado para todos los tipos de mensajes. Después de la activación, todos los eventos para el usuario que realiza la solicitud se enviarán al webhook de la aplicación mediante una solicitud POST. Actualmente, las suscripciones están limitadas en función de la configuración de tu cuenta. Si necesitas añadir más suscripciones, ponte en contacto con tu administrador de cuenta.

URL del recurso

https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/all.json

Información del recurso


Formato de respuesta	JSON
Requiere autenticación	Sí (OAuth de 3 participantes: clave de consumidor en lista de permitidos y token de acceso del usuario suscriptor)
Con límite de frecuencia	Sí
Solicitudes / ventana de 15 min (autenticación de usuario)	500

Parámetros


webhook_id (requerido)	Identificador del webhook. Definido en la ruta del recurso.

Ejemplo de solicitud

    $ curl --request POST
     --url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID/subscriptions/all.json
     --header 'authorization: OAuth oauth_consumer_key="WHITELISTED_CONSUMER_KEY", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="SUBSCRIBING_USER'S_ACCESS_TOKEN", oauth_version="1.0"'

Respuesta de ejemplo - satisfactoria

HTTP 204 SIN CONTENIDO

{}

Mensajes de error

Código	Mensaje
34	El webhook no existe o está asociado a otra aplicación de X.
348	La aplicación cliente no tiene permiso para acceder a las suscripciones de webhooks de este usuario.

GET account_activity/subscriptions/count

Devuelve el número de suscripciones que están activas actualmente en tu cuenta. Ten en cuenta que el endpoint /count requiere OAuth de solo aplicación, por lo que debes realizar las solicitudes usando un Bearer Token en lugar de usar el contexto de usuario.

URL del recurso

https://api.x.com/1.1/account_activity/subscriptions/count.json

Información del recurso


Formato de respuesta	Código de respuesta HTTP
Requiere autenticación	Sí (solo App - Bearer Token)
Con límite de frecuencia	Sí
Solicitudes por ventana de 15 minutos (autenticación de App)	15

Códigos de respuesta HTTP


Code	Mensaje
200	Correcto. Se devolverá el número de suscripciones del webhook solicitado.
401	Tu aplicación no tiene permiso para ver las suscripciones del webhook especificado.

Ejemplo de solicitud

    $ curl --request GET
     --url https://api.x.com/1.1/account_activity/subscriptions/count.json
     --header 'authorization: Bearer TOKEN'

Ejemplo de respuesta - éxito

HTTP 200

    {
      "account_name":"my-account",
      "subscriptions_count_all":"1",
      "subscriptions_count_direct_messages":"0",
      "provisioned_count":"50"
    }

Mensajes de error

Código	Mensaje
32	No se pudo autenticar tu identidad.

HTTP 401

    {
      "errors": [
        {
           "code": 32,
          "message": "Could not authenticate you."
        }
      ]
    }

GET account_activity/webhooks/:webhook_id/subscriptions/all

Proporciona un método para determinar si una configuración de webhook está suscrita a los eventos del usuario indicado. Si el contexto de usuario indicado tiene una suscripción activa con la aplicación indicada, devuelve 204 OK. Si el código de respuesta no es 204, entonces el usuario no tiene una suscripción activa. Consulta el código de respuesta HTTP y los mensajes de error a continuación para obtener más detalles.

URL del recurso

https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/all.json

Información del recurso


Formato de respuesta	JSON
Requiere autenticación	Sí (OAuth de 3 partes: clave de consumidor en lista de permitidos y token de acceso del usuario suscriptor)
Con límite de frecuencia	Sí
Solicitudes / ventana de 15 minutos (autenticación de usuario)	500

Parámetros


webhook_id (required)	Identificador de webhook. Definido en la ruta del recurso.

Ejemplo de solicitud

$ curl —request GET —url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID/subscriptions/all.json —header ‘authorization: OAuth oauth_consumer_key=“WHITELISTED_CONSUMER_KEY”, oauth_nonce=“GENERATED”, oauth_signature=“GENERATED”, oauth_signature_method=“HMAC-SHA1”, oauth_timestamp=“GENERATED”, oauth_token=“SUBSCRIBING_USER’S_ACCESS_TOKEN”, oauth_version=“1.0“‘

Ejemplo de respuesta - Éxito

HTTP 204 SIN CONTENIDO

{ }

GET account_activity/webhooks/:webhook_id/subscriptions/all/list

Devuelve una lista de las suscripciones actuales del tipo All Activity para el webhook especificado. Ten en cuenta que el endpoint /list requiere OAuth solo de aplicación, por lo que las solicitudes deben realizarse usando un Bearer Token en lugar de usar el contexto de usuario.

URL del recurso

https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/all/list.json

Información del recurso


Formato de la respuesta	Código de respuesta HTTP
Requiere autenticación	Sí (solo aplicación - Bearer Token)
Sujeto a límites de frecuencia	Sí
Solicitudes / ventana de 15 min (autenticación de la aplicación)	50

Parámetros


webhook_id (required)	ID del webhook. Definido en la ruta del recurso.

Códigos de respuesta HTTP

Código	Mensaje
200	Éxito. Se devolverá una lista de suscripciones del webhook solicitado.
401	Tu aplicación no tiene permisos para ver las suscripciones del webhook especificado.

Ejemplo de solicitud

$ curl —request GET —url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID/subscriptions/all/list.json —header ‘authorization: Bearer TOKEN’

Ejemplo de respuesta - correcta

HTTP 200

    {
      "webhook_id": "1234567890",
      "webhook_url": "https://your_domain.com/webhook/twitter/0",
      "application_id": "11231812",
      "subscriptions": [{
        "user_id": "20212306"
      }]
    }

Mensajes de error

Code	Message
32	No se pudo autenticar tu cuenta.

HTTP 401

    {
      "errors": [
        {
           "code": 32,
          "message": "Could not authenticate you."
        }
      ]
    }

DELETE account_activity/webhooks/:webhook_id

Elimina el webhook de la configuración de la aplicación proporcionada. El identificador del webhook se puede obtener mediante una llamada a GET /1.1/account_activity/webhooks.

URL del recurso

https://api.x.com/1.1/account_activity/webhooks/:webhook_id.json

Información del recurso


Formato de respuesta	JSON
Requiere autenticación	Sí (contexto de usuario: todos los tokens de consumidor y de acceso)
Con límite de frecuencia	Sí
Solicitudes / ventana de 15 min (autenticación de usuario)	15

Parámetros


webhook_id (obligatorio)	Identificador del webhook. Definido en la ruta del recurso.

Ejemplo de solicitud

    $ curl --request DELETE
     --url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID.json
     --header 'authorization: OAuth oauth_consumer_key="CONSUMER_KEY", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="ACCESS_TOKEN", oauth_version="1.0"'

Respuesta

HTTP 204 OK

{ }

DELETE account_activity/webhooks/:webhook_id/subscriptions/all (OBSOLETO)

Desactiva las suscripciones del contexto de usuario y de la aplicación proporcionados. Después de la desactivación, todos los eventos del usuario que realiza la solicitud dejarán de enviarse a la URL del webhook.

URL del recurso

https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/all.json

Información del recurso


Formato de respuesta	JSON
Requiere autenticación	Sí (OAuth de 3 partes: consumer key en lista blanca y access token del usuario suscrito)
Con límite de frecuencia	Sí
Solicitudes / ventana de 15 minutos (autenticación de usuario)	500

Parámetros


webhook_id (required)	Identificador del webhook. Definido en la ruta del recurso.

Ejemplo de solicitud

    $ curl --request DELETE
     --url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID/subscriptions/all.json
     --header 'authorization: OAuth oauth_consumer_key="WHITELISTED_CONSUMER_KEY", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="SUBSCRIBED_USER'S_ACCESS_TOKEN", oauth_version="1.0"'

Ejemplo de solicitud

{ }

DELETE /account_activity/webhooks/:webhook_id/subscriptions/:user_id/all.json

Desactiva la suscripción para el webhook y la ID de usuario especificados. Después de la desactivación, todos los eventos para el usuario que realiza la solicitud dejarán de enviarse a la URL del webhook. Ten en cuenta que este endpoint requiere OAuth de solo aplicación, por lo que las solicitudes deben realizarse usando un Bearer Token en lugar de un contexto de usuario.

URL del recurso

https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/:user_id/all.json

Información del recurso


Formato de respuesta	JSON
Requiere autenticación	Sí (solo App - Bearer Token)
Sujeto a límite de frecuencia	Sí
Solicitudes por ventana de 15 minutos	500

Ejemplo de solicitud

    $ curl --request DELETE
     --url https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/:user_id/all.json
     --header 'authorization: Bearer TOKEN'

Respuesta

HTTP 204 NO CONTENT

Mensajes de error

Código	Mensaje
404	Lo sentimos, esa página no existe. - Esto suele ocurrir cuando el id de usuario especificado en realidad no está suscrito.

Replay API

POST /1.1/account_activity/replay/webhooks/:webhook_id/subscriptions/all.json ¶ Envía una solicitud para recuperar actividades de hasta los últimos cinco días de todas las suscripciones presentes durante las ventanas de fecha y hora especificadas en la solicitud. Si tu webhook tiene suscripciones de usuario activas, también recibirás esos eventos de forma simultánea. Nota: realizamos un CRC antes de entregar eventos de replay.


Request Method	HTTP POST
URL	/1.1/account_activity/replay/webhooks/:webhook_id/subscriptions/all.json?from_date=yyyymmddhhmm&to_date=yyyymmddhhmm
Response Format	JSON
Requires Authentication	Sí (solo aplicación - Bearer Token)
Rate Limit	5 solicitudes cada 15 minutos. Actualmente no existe un límite máximo para la cantidad de jobs de replay que se pueden solicitar.
from_date	La marca de tiempo UTC más antigua (inicial) a partir de la cual se proporcionarán los eventos; debe estar en el formato ‘yyyymmddhhmm’. La marca de tiempo tiene granularidad de minutos y es inclusiva (es decir, 12:00 incluye el minuto 00). Las horas válidas deben estar dentro de los últimos 5 días, en hora UTC, y no ser más recientes que 31 minutos antes del momento actual. Se recomienda que from_date y to_date estén dentro de un intervalo de aproximadamente 2 horas.
to_date	La marca de tiempo UTC más reciente (final) hasta la cual se proporcionarán los eventos; debe estar en el formato ‘yyyymmddhhmm’. La marca de tiempo tiene granularidad de minutos y es exclusiva (es decir, 12:30 no incluye el minuto 30 de la hora). Las horas válidas deben estar dentro de los últimos 5 días, en hora UTC, y no ser más recientes que 10 minutos antes del momento actual.

Respuestas

Las siguientes respuestas pueden ser devueltas por la API. La mayoría de los códigos de error se devuelven con una cadena que incluye detalles adicionales en el cuerpo. Para respuestas que no sean 200, debes resolver el error e intentarlo de nuevo.

Status	Text	Error Code	Description	Message
202	Accepted	N/A	La solicitud se realizó correctamente y se enviarán las actividades.	N/A
400	Bad Request	214	El webhook se ha marcado como no válido.	El webhook está marcado como no válido y requiere una verificación CRC.
400	Bad Request	357	Falta un parámetro de consulta.	: queryParam es obligatorio.
400	Bad Request	358	La ruta o el parámetro de consulta tiene un formato incorrecto.	No se puede analizar el parámetro.
400	Bad Request	360	El parámetro de ruta es negativo.	webhook_id: [] no es mayor o igual que 0.
400	Bad Request	368	from_date o to_date no está en el pasado.	: [<field_value>] no está en el pasado.
400	Bad Request	356	from_date debe ser anterior a to_date.	from_date debe ser anterior a to_date.
400	Bad Request	356	from_date debe estar dentro de los últimos 5 días.	from_date debe estar dentro de los últimos 5 días.
401	Unauthorized	32	La autenticación HTTP falló porque se proporcionó autenticación OAuth de 3 patas (3-legged OAuth).	Método de autenticación no válido. Usa únicamente autenticación de aplicación.
401	Unauthorized	61	El Client no tiene permiso para solicitar este método.	El Client no tiene permiso para solicitar este método.
403	Forbidden	200	El Client no tiene una cuenta empresarial con Replay habilitado.	Se requiere una cuenta empresarial de Account Activity API con Replay. Confirma que tienes una cuenta empresarial y que Replay está habilitado.
404	Not Found	34	webhook_id inexistente; desajuste entre webhook_id y application_id.	El webhook no existe o está asociado con una aplicación de X diferente.
409	Conflict	355	Hay una solicitud en curso y deberá terminar de procesarse antes de realizar otra.	Ya hay un trabajo de Replay en curso para este webhook.
429	Too Many Requests	88	Límite de frecuencia alcanzado (se alcanzó el límite del número de solicitudes por período de tiempo).	Demasiadas solicitudes. Reduce la frecuencia de tus solicitudes a la API.
500	Internal Server Error	0	Error interno del servidor.	Error interno del servidor.
503	Service Unavailable	67	Uno o más servicios dependientes en X no están disponibles.	Error del servidor de X. Reintenta usando un patrón de reintentos exponenciales.

Mensaje de “Job completed successfully”

Una vez que el job se complete correctamente, la API Account Activity Replay entregará el siguiente evento de finalización de job. Cuando recibas este evento, el job habrá terminado de ejecutarse y podrás enviar otro.

{
  "replay\_job\_status": {
    "webhook_id": "1234577122340233217",
    "job_state": "Complete",
    "job\_state\_description": "Job completed successfully"
    "job_id": "1095098195724558337"
  }
}

Mensaje “Job failed to complete”

En caso de que tu job no se complete correctamente, devolveremos el siguiente mensaje para animarte a volver a intentar tu job de Replay. Una vez que recibas este evento, el job habrá terminado de ejecutarse y podrás enviar otro.

{
  "replay\_job\_status": {
    "webhook_id": "123451374207332352",
    "job_state": "Incomplete",
    "job\_state\_description": "Job failed to deliver all events, please retry your replay job",
    "job_id": "1093226942650736640"
  }
}

Ejemplo de solicitud con curl

    curl --request POST  --url 'https://api.x.com/1.1/account_activity/replay/webhooks/:webhook_id/subscriptions/all.json?from_date=yyyymmddhhmm&to_date=yyyymmddhhmm'
    --header 'authorization: Bearer TOKEN'

Ejemplo de respuesta

HTTP 202

{
  "job_id": "1234567890",
  "created_at": "2016-06-02T23:54:02Z"
}

​Serie de videos

​Resumen de funciones

​Administrar webhooks y usuarios suscritos

​Administrar un webhook:

​Gestión de usuarios suscritos:

​Artículos relacionados

​Un recorrido en video por la Account Activity API

​Introducción a los webhooks

​1. Crea una App de X.

​2. Obtener acceso a Account Activity API

​3. Desarrollar la aplicación consumidora de webhooks

​4. Validar la configuración

​Proteger los webhooks

​Comprobaciones de desafío-respuesta

​La solicitud de CRC se producirá:

​Requisitos de la respuesta:

​Bibliotecas HMAC específicas del lenguaje:

​Ejemplo de generación de token de respuesta en Python:

​Ejemplo de respuesta JSON:

​Otros ejemplos:

​Validación opcional del encabezado de firma

​Directrices de seguridad adicionales

​Bloques de red agregados de X

​Configuraciones de servidor recomendadas

​Administrar webhooks y suscripciones

​Creación y actualización de webhooks

​Endpoints de administración de la configuración de webhooks:

​¿Por qué no puedo simplemente actualizar la URL del webhook?

​Añadir y eliminar suscripciones de usuario

​Endpoints para la gestión de suscripciones

​Reintentos

​¿Qué son los reintentos?

​Cronograma de reintentos

​Cronograma de reintentos

​Estructura del objeto de datos de Account Activity

​tweet_create_events (Publicaciones, Retweets, Respuestas, Tweets citados)

​tweet_create_events (@menciones)

​favorite_events

​follow_events

​unfollow_events

​block_events

​unblock_events

​mute_events

​unmute_events

​user_event

​direct_message_events

​direct_message_indicate_typing_events

​direct_message_mark_read_events

​tweet_delete_events

​API de Reproducción de Actividad de Cuenta

​Uso de Account Activity Replay API

​Limitaciones

​Disponibilidad de datos y tipos

​Introducción a la migración

​Guía de migración: migrar de User Streams/Site Streams a Account Activity API

​Resumen de los cambios

​APIs en desuso

​APIs de sustitución

​Diferencias y consideraciones de migración

​Nuevas funcionalidades

​Gestión de suscripciones de usuario

​Cómo migrar

​Sigue los pasos a continuación para migrar fácilmente de la Site Streams API a la Account Activity API

​El panel de Account Activity (aplicación de ejemplo de Account Activity API)

​Actividades disponibles

​Tipos de mensajes de streaming en desuso

​Tipos de eventos obsoletos

​Guía de migración de Mensajes Directos

​Resumen de los cambios

​Nuevas funciones

​Diferencias y consideraciones de migración

​Nuevo objeto de Mensaje Directo

​Resumen

​Envío de Mensajes Directos

​Resumen

​Recuperar Mensajes Directos

​Resumen

​Eliminación de Mensajes Directos

​Resumen

​Preguntas frecuentes

Serie de videos

Resumen de funciones

Administrar webhooks y usuarios suscritos

Administrar un webhook:

Gestión de usuarios suscritos:

Artículos relacionados

Un recorrido en video por la Account Activity API

Introducción a los webhooks

1. Crea una App de X.

2. Obtener acceso a Account Activity API

3. Desarrollar la aplicación consumidora de webhooks

4. Validar la configuración

Proteger los webhooks

Comprobaciones de desafío-respuesta

La solicitud de CRC se producirá:

Requisitos de la respuesta:

Bibliotecas HMAC específicas del lenguaje:

Ejemplo de generación de token de respuesta en Python:

Ejemplo de respuesta JSON:

Otros ejemplos:

Validación opcional del encabezado de firma

Directrices de seguridad adicionales

Bloques de red agregados de X

Configuraciones de servidor recomendadas

Administrar webhooks y suscripciones

Creación y actualización de webhooks

Endpoints de administración de la configuración de webhooks:

¿Por qué no puedo simplemente actualizar la URL del webhook?

Añadir y eliminar suscripciones de usuario

Endpoints para la gestión de suscripciones

Reintentos

¿Qué son los reintentos?

Cronograma de reintentos

Cronograma de reintentos

Estructura del objeto de datos de Account Activity

tweet_create_events (Publicaciones, Retweets, Respuestas, Tweets citados)

tweet_create_events (@menciones)

favorite_events

follow_events

unfollow_events

block_events

unblock_events

mute_events

unmute_events

user_event

direct_message_events

direct_message_indicate_typing_events

direct_message_mark_read_events

tweet_delete_events

API de Reproducción de Actividad de Cuenta

Uso de Account Activity Replay API

Limitaciones

Disponibilidad de datos y tipos

Introducción a la migración

Guía de migración: migrar de User Streams/Site Streams a Account Activity API

Resumen de los cambios

APIs en desuso

APIs de sustitución

Diferencias y consideraciones de migración

Nuevas funcionalidades

Gestión de suscripciones de usuario

Cómo migrar

Sigue los pasos a continuación para migrar fácilmente de la Site Streams API a la Account Activity API

El panel de Account Activity (aplicación de ejemplo de Account Activity API)

Actividades disponibles

Tipos de mensajes de streaming en desuso

Tipos de eventos obsoletos

Guía de migración de Mensajes Directos

Resumen de los cambios

Nuevas funciones

Diferencias y consideraciones de migración

Nuevo objeto de Mensaje Directo

Resumen

Envío de Mensajes Directos

Resumen

Recuperar Mensajes Directos

Resumen

Eliminación de Mensajes Directos

Resumen

Preguntas frecuentes