API de Actividad de Cuenta: Empresarial

Este endpoint se ha actualizado para incluir metadatos de edición de publicaciones. Obtenga más información sobre estos metadatos en la página de fundamentos de «Editar publicaciones». Este endpoint se utiliza a menudo junto con los endpoints de Mensajes Directos. Hemos lanzado nuevos endpoints de Mensajes Directos v2. Tenga en cuenta que las API de Actividad de Cuenta Empresarial y Premium admiten mensajes uno a uno de v2, pero aún no admiten conversaciones en grupo.

Overview Enterprise La API de Actividad de Cuenta le permite suscribirse a actividades en tiempo real relacionadas con una cuenta de usuario mediante webhooks. Esto significa que puede recibir publicaciones en tiempo real, Mensajes Directos y otros eventos de cuenta de una o más de sus cuentas propias o suscritas a través de una sola conexión. Recibirá todas las actividades relacionadas a continuación para cada suscripción de usuario en su registro de webhook:

Tipos de actividad
* Publicaciones (por el usuario) * Eliminaciones de publicaciones (por el usuario) * @menciones (del usuario) * Respuestas (a o del usuario) * Retuits (por el usuario o del usuario) * Retuits con comentario (por el usuario o del usuario) * Retuits de retuits con comentario (por el usuario o del usuario) * Me gusta (por el usuario o del usuario) * Acciones de seguir (por el usuario o del usuario) * Acciones de dejar de seguir (por el usuario)	* Bloqueos (por el usuario) * Desbloqueos (por el usuario) * Silenciamientos (por el usuario) * Dejar de silenciar (por el usuario) * Mensajes Directos enviados (por el usuario) * Mensajes Directos recibidos (por el usuario) * Indicadores de escritura (al usuario) * Confirmaciones de lectura (al usuario) * Revocaciones de suscripción (por el usuario)

Tenga en cuenta - No entregamos datos de la línea de tiempo principal a través de la API de Actividad de Cuenta. Utilice GET statuses/home_timeline para obtener estos datos.

Serie de videos

¡Consulte nuestra serie de videos de cuatro partes sobre la API de Actividad de Cuenta para ponerse al día!

Resumen de características

Nivel	Precio	Número de suscripciones únicas	Número de webhooks	Confiabilidad y recuperación de actividad
Empresarial	Contacte con ventas	Hasta 500+	3+	Reintentos y Reproducción

¿Tiene preguntas? ¿Se encuentra con errores?
- Lea nuestras Preguntas frecuentes o Guía de resolución de errores.
Explore nuestros ejemplos de código:
- Panel de la API de Actividad de Cuenta Empresarial, una aplicación web en Node que muestra eventos de webhook utilizando el nivel empresarial de la API de Actividad de Cuenta e incluye funcionalidad de Reproducción.
- El chatbot SnowBot, una aplicación web en Ruby construida sobre las APIs de Actividad de Cuenta empresarial y de Mensajes Directos.

Administrar webhooks y usuarios suscritos

⏱ 10 min de lectura La API de Actividad de Cuenta empresarial proporciona mensajes JSON basados en webhooks cada vez que hay eventos asociados con cuentas de X suscritas a su servicio. X entrega esas actividades a su webhook registrado. En los siguientes pasos, aprenderá cómo administrar webhooks y usuarios suscritos. Aprenderá cómo registrar, ver y eliminar tanto webhooks como usuarios suscritos. Usaremos comandos cURL simples para realizar solicitudes a los diversos endpoints de la API. cURL es una herramienta de línea de comandos para obtener o enviar solicitudes utilizando la sintaxis URL. Necesitará:

Una App de X registrada - regístrese aquí
Un token de portador - aprenda más
Un webhook que pasa una Verificación de Desafío-Respuesta (CRC) - aprenda más
Una cuenta empresarial - [solicite aquí]https://developer.x.com/en/products/x-api/enterprise

Antes de comenzar, le recomendamos que consulte nuestro repositorio de GitHub aquí que proporciona una aplicación web de muestra y scripts de ayuda para comenzar con la API de Actividad de Cuenta de X

Administrar un webhook:

El uso de un webhook le permite suscribirse a actividades en tiempo real relacionadas con una cuenta de usuario mediante una sola 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 dada.La URL se validará mediante una solicitud CRC antes de guardarla. Una vez que haya registrado un webhook, asegúrese de documentar el ID del webhook, ya que lo necesitará más adelante.Copie la siguiente solicitud cURL en su línea de comandos después de realizar los siguientes cambios:

URL <URL> p. ej. https://yourdomain.com/webhooks/twitter/
Clave del consumidor <CONSUMER_KEY> p. ej. xvz1evFS4wEEPTGEFPHBog

Token de acceso <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"'

Gestión de usuarios suscritos:

Una vez que hayas registrado un webhook, puedes agregar un usuario suscrito a la API de Actividad de Cuenta para comenzar a recibir sus actividades de cuenta.

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

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

ID de webhook <:WEBHOOK_ID> p. ej. 1234567890
Clave de consumidor <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"'

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

Artículos referenciados

Resumen de la verificación de desafío-respuesta (CRC)
[Tipos de datos de actividad de cuenta](/x-api/enterprise-gnip-2.0/fundamentals/account-activity#account-activity-data-object-structure
Gestión de webhooks y suscripciones

Un recorrido en video de la API de Actividad de Cuenta

En este recorrido en video, aprenderá sobre las capacidades de los niveles premium y empresariales de la API de Actividad de Cuenta. Al final de este video, aprenderá sobre las siguientes capacidades.

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

¿Tiene preguntas? ¿Está experimentando errores?
- Lea nuestras Preguntas frecuentes o Guía de solución de errores.
Explora nuestros ejemplos de código:
- Panel de la API de Actividad de Cuenta Empresarial, una aplicación web en Node que muestra eventos de webhook utilizando el nivel empresarial de la API de Actividad de Cuenta e incluye la funcionalidad de Replay.
- El chatbot SnowBot, una aplicación web en Ruby construida sobre las APIs empresariales de Actividad de Cuenta y Mensajes Directos.

Empresarial

Primeros pasos con webhooks

La API de Actividad de Cuenta es una API basada en webhooks que envía eventos de cuenta a una aplicación web que tú desarrollas, despliegas y alojas. Hay varios detalles de ‘plomería’ 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 API de Actividad de Cuenta y desarrollar una aplicación web que consuma eventos de webhook.

1. Crear una app de X.

Cree una app de X con una cuenta de desarrollador aprobada en el Portal de desarrolladores. Si está creando la app en nombre de su empresa, se recomienda que cree la app con una cuenta corporativa de X. Para solicitar una cuenta de desarrollador, haga clic aquí.
Habilite “Leer, escribir y acceder a mensajes directos” en la pestaña de permisos de la página de su app.
En la pestaña “Claves y tokens de acceso”, tome nota de la Clave de consumidor (Clave de API) y el Token de consumidor (Secreto de API) de su app.
En la misma pestaña, genere el Token de acceso y secreto del token de acceso de su app. Necesitará estos tokens de acceso para registrar la URL de su webhook, que es donde X enviará los eventos de la cuenta.
Si no está familiarizado con el Inicio de sesión con X y cómo funcionan los contextos de usuario con la API de X, revise Obtención de tokens de acceso. A medida que agregue cuentas para las que desea recibir eventos, las suscribirá usando los tokens de acceso de esa cuenta.
Tome nota del ID numérico de su app, como se ve en la página “Apps” del Portal de desarrolladores. Cuando solicite acceso a la API de Actividad de Cuenta, necesitará este ID de la app.

2. Obtener acceso a la API de Actividad de Cuenta

Después de crear una app de X, el siguiente paso es solicitar acceso a la API de Actividad de Cuenta. La API de Actividad de Cuenta solo está disponible en Empresarial, por lo que necesitará enviar una solicitud utilizando el enlace a continuación.

3. Desarrollar una aplicación web consumidora de webhooks

Una vez que hayas recibido acceso a la API de actividad de cuenta, necesitas desarrollar, desplegar y alojar una aplicación web que recibirá eventos de webhook de X.

Crea una aplicación web con una URL para usar como tu webhook y recibir eventos. Este es el endpoint desplegado en tu servidor para escuchar los eventos de webhook entrantes de X.
- La ruta URI depende completamente de ti. Este ejemplo sería válido: https://mydomain.com_/service/listen_
- Si estás escuchando 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 para proteger webhooks, un primer paso es escribir código que reciba una solicitud GET de comprobación de respuesta de desafío de X (CRC) y responda con una respuesta JSON correctamente formateada.
Registra tu URL de webhook. Realizarás una solicitud POST a un endpoint /webhooks.json?url=. Al hacer esta solicitud, X enviará una solicitud CRC a tu aplicación web. Cuando un webhook se registre con éxito, la respuesta incluirá un id de webhook. Este id de webhook se necesita más adelante para realizar ciertas solicitudes a la API de actividad de cuenta.
X enviará eventos de webhook de cuenta a la URL que registraste. Asegúrate de que tu aplicación web admita solicitudes POST para los eventos entrantes. Estos eventos vendrán codificados en JSON. Consulta AQUÍ para ver ejemplos de payloads JSON de webhook.
Una vez que tu aplicación web esté lista, el siguiente paso es agregar cuentas para recibir sus actividades. Al agregar (o eliminar) cuentas, realizarás solicitudes POST que referencien el id de la cuenta. Consulta nuestra guía sobre la gestión de suscripciones para obtener más información.

4. Validar la configuración

Para validar que tu App y webhook estén configurados correctamente, da «Me gusta» a una Publicación publicada por una de las cuentas de X a las que tu App está suscrita. Deberías recibir un favorite_events mediante una solicitud POST a la URL de tu webhook por cada «Me gusta» que reciban tus suscriptores.
Ten en cuenta que puede tomar hasta 10 segundos para 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 de consumidor y secreto y el token de acceso de usuario y secreto del propietario de la App.
Todos los Mensajes Directos entrantes se entregarán mediante webhooks. Todos los Mensajes Directos enviados mediante POST direct_messages/events/new (message_create) también se entregarán mediante webhooks. Esto permite que tu aplicación web se entere de los Mensajes Directos enviados desde 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 dos usuarios que utilizan tu aplicación web para Mensajes Directos en la misma conversación, tu webhook recibirá dos eventos duplicados (uno para cada usuario). Tu aplicación web debe tener en cuenta esto.
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 varias veces (una por cada aplicación web).
En algunos casos, tu webhook puede recibir eventos duplicados. La aplicación de tu webhook debe ser tolerante a esto y eliminar duplicados según el ID del evento.
No esperes que la respuesta de Respuesta rápida siga inmediatamente a una solicitud. Un usuario puede ignorar una solicitud de Respuesta rápida y responder mediante un Mensaje Directo tradicional. El usuario también puede proporcionar una respuesta de Respuesta rápida a una solicitud a la que no haya respondido antes en el hilo de mensajes.
Consulta el código de ejemplo:
- Panel de la API de Actividad de Cuenta Empresarial, una aplicación web en Node que muestra eventos de webhook utilizando el nivel empresarial de la API de Actividad de Cuenta e incluye funcionalidad de Replay.
- El chatbot SnowBot, una aplicación web en Ruby construida sobre las APIs de Actividad de Cuenta y Mensajes Directos. Esta base de código incluye un script para ayudar a configurar webhooks de la API de Actividad de Cuenta.

Proteger webhooks

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

Las verificaciones de desafío-respuesta permiten que X confirme la propiedad de la aplicación web que recibe eventos de webhook.
El encabezado de firma en cada solicitud POST le permite confirmar que X es la fuente de los webhooks entrantes.

Verificaciones de desafío-respuesta

Para verificar que eres el propietario tanto de la app como de la URL del webhook, X realizará una Verificación de Desafío-Respuesta (CRC), que no debe confundirse con una verificación de redundancia cíclica. Cuando se envíe una 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 necesita generar un response_token cifrado basado en el parámetro crc_token y el Consumer Secret de tu app (detalles a continuación). El response_token debe codificarse en JSON (ver ejemplo a continuación) y devolverse en un plazo de tres segundos. Cuando sea exitoso, se devolverá un id de webhook. Se enviará una CRC cuando registres tu URL de webhook, por lo que implementar tu código de respuesta CRC es un primer paso fundamental. Una vez que tu webhook esté establecido, X activará una CRC aproximadamente cada 24 horas desde la última vez que recibimos una respuesta exitosa. Tu app también puede activar una CRC cuando sea necesario haciendo una solicitud PUT con tu id de webhook. Activar una CRC es útil a medida que desarrollas tu aplicación de webhook, después de implementar nuevo código y reiniciar tu servicio. El crc_token debe esperarse que cambie para cada solicitud CRC entrante y debe usarse como el mensaje en el cálculo, donde tu Consumer Secret es la clave. En el caso de que la respuesta no se envíe en 3 segundos o se vuelva inválida, los eventos dejarán de enviarse al webhook registrado.

La solicitud CRC se realizará:

Cuando se registre una URL de webhook.
Aproximadamente cada hora para validar su URL de webhook.
Puede activar manualmente un CRC mediante una solicitud PUT. Al desarrollar su cliente de webhook, planifique activar manualmente el CRC a medida que desarrolle su respuesta CRC.

Requisitos de respuesta:

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

Bibliotecas HMAC específicas por lenguaje:

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

Lo siguiente define una ruta en una aplicación web Flask de Python 2.7 que responderá correctamente a la verificación de la 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 secreto 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 correctamente formateada
  return json.dumps(response)

Ejemplo de respuesta JSON:

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

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

Otros ejemplos:

AQUÍ es un ejemplo de método de respuesta CRC escrito en Node/JS.
AQUÍ es un ejemplo de método de respuesta CRC escrito en Ruby (vea el generate_crc_response y la ruta /GET que recibe eventos CRC).

Validación opcional de la firma en el encabezado

Al recibir una solicitud POST de X, al enviar una solicitud GET para crear un webhook o al enviar 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 la fuente de los datos sea X. La firma hash de la solicitud POST comienza con sha256=, lo que indica el uso de HMAC SHA-256 para generar un hash con el secreto del consumidor de su App de X y la carga útil. El hash GET se calcula a partir de la cadena de parámetros de consulta crc_token=

token&amp;nonce=

nonce. Pasos para validar una solicitud

Cree un hash usando su secreto del consumidor y el cuerpo de la carga útil entrante.
Compare el hash creado con el valor de x-twitter-webhooks-signature codificado en base64. Use un método como compare_digest para reducir la vulnerabilidad a ataques de tiempo.

Directrices de seguridad adicionales

A continuación se presentan directrices de seguridad adicionales que debe considerar para su aplicación web. No implementar estas directrices no impedirá el funcionamiento de su webhook, pero son altamente recomendadas por el equipo de Seguridad de la Información de X. Si no está familiarizado con las recomendaciones siguientes, consulte con su administrador del servidor.

Bloques de red agregados de X

Para mayor seguridad, puede desear agregar los siguientes bloques de red agregados a una lista blanca:

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

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 los tickets de sesión a menos que rote las claves de los tickets de sesión.
Establecer la opción «ssl_prefer_server_ciphers» o «SSLHonorCipherOrder» en la configuración SSL en «on».
Asegurarse de que la lista de cifrados sea una lista moderna como: 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

Gestión de webhooks y suscripciones

Creación y cambio de webhooks

Para cambiar las URLs de los webhooks, debe eliminar el webhook existente y luego crear uno nuevo. Tenga en cuenta que al hacer esto, deberá volver a agregar las suscripciones de usuario al nuevo webhook.

Endpoints para la gestión de la configuración de webhooks:


Método	Empresarial
Registra una URL de webhook / Genera un webhook_id	POST webhooks
Devuelve todas las URLs de webhook y sus estados	GET webhooks
Eliminar la configuración actual de webhook de la App	DELETE webhooks/:webhook_id
Desencadenar manualmente una solicitud CRC	PUT webhooks/:webhook_id

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

¿Por qué son inmutables las configuraciones de webhook? X se toma la seguridad muy en serio. Si cambia la URL de su webhook, existe la posibilidad de que la clave del consumidor y el secreto del consumidor de su aplicación hayan sido comprometidos. Al requerir la creación de una nueva configuración de webhook, también se le exige que se vuelva a suscribir a los eventos de su usuario. Esto implica el uso de tokens de acceso que es menos probable que una parte maliciosa posea. Como resultado, se reduce la probabilidad de que otra parte reciba la información privada de su usuario.

Agregar & eliminar suscripciones de usuario

El soporte para miles de suscripciones está disponible con el nivel Empresarial. Si ya tiene un gerente de cuenta, póngase en contacto con él para cualquier pregunta. Para solicitar acceso a las APIs Empresariales, haga clic aquí.

Endpoints de gestión de suscripciones


Método	Empresarial
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 usando OAuth solo de la aplicación	DELETE webhooks/:webhook_id/subscriptions/:user_id/all.json

API de Actividad de Cuenta: Empresarial

Tenga en cuenta: X debe habilitar el acceso a la API de Actividad de Cuenta para su App de desarrollador antes de que pueda comenzar a usar la API. Para este fin, asegúrese de compartir el ID de la App que pretende usar para fines de autenticación con su gerente de cuenta o equipo de soporte técnico.

La API de Actividad de Cuenta consta de un conjunto de endpoints que le permiten crear y gestionar suscripciones de usuario para recibir actividades de cuenta en tiempo real de todas sus cuentas suscritas a través de una sola conexión. Hay dos métodos de autenticación disponibles con la API de Actividad de Cuenta (OAuth 1.0a y OAuth 2.0 Bearer Token. El método de autenticación que debe usar dependerá del endpoint que esté 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 la aplicación dada	POST account_activity/webhooks	✓
Devolver todas las URL y sus estados para la aplicación dada	GET account_activity/webhooks		✓
Activar una verificación de respuesta al desafío (CRC) para la URL de un webhook dado	PUT account_activity/webhooks/:webhook_id	✓
Suscribir la aplicación a los eventos de la cuenta de un usuario	POST account_activity/webhooks/:webhook_id/subscriptions/all	✓ *
Devolver el número de suscripciones actualmente activas	GET account_activity/subscriptions/count		✓
Verificar 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 las suscripciones actualmente activas	GET account_activity/webhooks/:webhook_id/subscriptions/all/list		✓
Eliminar un webhook	DELETE account_activity/webhooks/:webhook_id	✓
[DEPRECATED] Desactivar una suscripción para el contexto de usuario proporcionado y la aplicación	DELETE account_activity/webhooks/:webhook_id/subscriptions/all	✓ *
Desactivar una suscripción usando OAuth solo de aplicación	DELETE /account_activity/webhooks/:webhook_id/subscriptions/:user_id/all.json		✓
Reenviar 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 que se suscribe. _ Para aquellos endpoints que requieren autenticación en contexto de usuario de OAuth 1.0a, necesitará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 siguientes tres endpoints, realizas acciones de escritura dentro del contexto de tu aplicación (no se involucran usuarios de X). Por lo tanto, los Access Tokens que necesitas proporcionar son los que pertenecen a tu App de desarrollador. Estos se pueden generar directamente desde el Portal de desarrolladores, en la pestaña “Keys and tokens” para tu App.

POST account_activity/webhooks: Registre una nueva URL de webhook para el contexto de la aplicación dada
PUT account_activity/webhooks/:webhook_id: Inicie una verificación de respuesta de desafío (CRC) para la URL de un webhook dado
DELETE account_activity/webhooks/:webhook_id: Elimine un webhook

Por otro lado, en el caso de los siguientes tres endpoints, se realiza una solicitud que permite que su aplicación acceda a datos protegidos en nombre de un usuario de X (por ejemplo, Mensajes Directos). Por lo tanto, debe proporcionar los Tokens de Acceso que pertenecen al usuario suscrito en cuestión. Los tokens de acceso requeridos se pueden obtener utilizando el flujo de OAuth de 3 patas (consulte OAuth 1.0a: cómo obtener los Tokens de Acceso de un usuario). Estos endpoints han sido marcados con un asterisco en la tabla anterior (*).

POST account_activity/webhooks/:webhook_id/subscriptions/all: Suscriba la aplicación a los eventos de cuenta de un usuario
GET account_activity/webhooks/:webhook_id/subscriptions/all: Verifique si una configuración de webhook está suscrita a los eventos de un usuario
DELETE account_activity/webhooks/:webhook_id/subscriptions/all: Desactive una suscripción para el contexto de usuario proporcionado y la aplicación [DEPRECATED]

Por favor, tenga en cuenta: Asegúrese de que su App de desarrollador esté habilitada para “Lectura, Escritura y Mensajes Directos.” Puede cambiar esta configuración en la sección Proyectos y Apps de su cuenta de desarrollador, bajo “Permisos de la App” para la App de desarrollador seleccionada. Tendrá que regenerar las credenciales de su App después de cambiar la configuración de permisos.

Una lista de todos los endpoints disponibles con la API de Actividad de Cuenta, incluyendo descripciones asociadas y ejemplos de solicitudes cURL con ejemplos de implementación de autenticación, se puede encontrar en ladocumentación de referencia de la API. Para obtener información adicional, consulte la aplicación web de muestra y scripts de ayuda de XDev para comenzar con la API de Actividad de Cuenta Empresarial.

Por favor, tenga en cuenta: X debe habilitar el acceso a la API de Actividad de Cuenta para su App de desarrollador antes de que pueda comenzar a usar la API. Para este fin, asegúrese de compartir el ID de la App que tiene la intención de usar para fines de autenticación con su gerente de cuenta o equipo de soporte técnico.

La API de Actividad de Cuenta consiste en un conjunto de endpoints que le permiten crear y gestionar suscripciones de usuario para recibir actividades de cuenta en tiempo real para todas sus cuentas suscritas a través de una sola conexión. Hay dos métodos de autenticación disponibles con la API de Actividad de Cuenta (OAuth 1.0a y Token de Portador de OAuth 2.0). El método de autenticación que debe usar dependerá del endpoint que esté utilizando.


Descripción	Endpoint	OAuth 1.0a (contexto de usuario)	OAuth 2.0 Bearer Token (de aplicación únicamente)
Registrar una nueva URL de webhook para el contexto de la aplicación dada	POST account_activity/webhooks	✓
Devolver todas las URL y sus estados para la aplicación dada	GET account_activity/webhooks		✓
Activar la verificació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 la cuenta de un usuario	POST account_activity/webhooks/:webhook_id/subscriptions/all	✓ *
Devolver el número de suscripciones actualmente activas	GET account_activity/subscriptions/count		✓
Verificar 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 las suscripciones actualmente activas	GET account_activity/webhooks/:webhook_id/subscriptions/all/list		✓
Eliminar un webhook	DELETE account_activity/webhooks/:webhook_id	✓
[DEPRECATED] Desactivar una suscripción para el contexto de usuario proporcionado y la aplicación	DELETE account_activity/webhooks/:webhook_id/subscriptions/all	✓ *
Desactivar una suscripción usando OAuth de aplicación únicamente	DELETE /account_activity/webhooks/:webhook_id/subscriptions/:user_id/all.json		✓
Reenviar 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 que se suscribe. _ Para esos endpoints que requieren autenticación con contexto de usuario de OAuth 1.0a, necesitarás proporcionar las siguientes credenciales para autenticar la solicitud:

Claves de consumidor (Clave de API y Secreto)
Tokens de acceso (Token de acceso y Secreto)

En el caso de los siguientes tres endpoints, realizas acciones de escritura dentro del contexto de tu aplicación (no hay usuarios de X involucrados). Por lo tanto, los tokens de acceso que necesitas proporcionar son los que pertenecen a tu App de desarrollador. Estos se pueden generar directamente desde el Portal de desarrolladores, en la pestaña “Claves y tokens” para tu App.

POST account_activity/webhooks: Registrar una nueva URL de webhook para el contexto de la aplicación dada
PUT account_activity/webhooks/:webhook_id: Desencadenar una verificació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 Tokens de Acceso que pertenecen al usuario suscrito en cuestión. Los tokens de acceso requeridos se pueden obtener utilizando el flujo de OAuth de 3 patas (ver OAuth 1.0a: cómo obtener los Tokens de Acceso de un usuario). Estos endpoints han sido marcados con un asterisco en la tabla anterior (*).

POST account_activity/webhooks/:webhook_id/subscriptions/all: Suscribir la aplicación a los eventos de cuenta de un usuario
GET account_activity/webhooks/:webhook_id/subscriptions/all: Verificar 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 aplicación proporcionados [DEPRECATED]

Por favor, ten en cuenta: Asegúrate de que tu App de desarrollador esté habilitada para “Lectura, Escritura y Mensajes Directos”. Puedes cambiar esta configuración en la sección de Proyectos y Apps de tu cuenta de desarrollador, bajo “Permisos de la App” para la App de desarrollador seleccionada. Tendrás que regenerar las credenciales de tu App después de cambiar la configuración de permisos.

Una lista de todos los endpoints disponibles con la API de Actividad de Cuenta, incluyendo descripciones asociadas y ejemplos de solicitudes cURL con ejemplos de implementación de autenticación, se puede encontrar en la documentación de referencia de la API. Para obtener información adicional, consulta la aplicación web de muestra y scripts de ayuda de XDev para comenzar con la API de Actividad de Cuenta Empresarial.

Reintentos

Empresarial Uno de los beneficios del nivel empresarial de la API de Actividad de Cuenta es un mecanismo de reintento para eventos de webhook. Si no se recibe un código de respuesta HTTP 200 («éxito»), el servidor de X iniciará un mecanismo de reintento, reenviando el evento de webhook hasta tres veces en un período de cinco minutos. Este servicio de reintento para eventos de webhook ayuda a garantizar la confiabilidad y la recuperación de eventos cuando se producen problemas de red y durante las interrupciones del servicio en el lado del cliente y los despliegues.

¿Qué son los reintentos?

La API de Actividad de Cuenta ofrece una función de reintento cuando la aplicación web del cliente no devuelve una respuesta 200 de éxito para un evento de webhook de actividad de cuenta. Cuando el cliente no confirma la recepción exitosa de un evento, X asume que el evento no fue recibido. Si se recibe una respuesta distinta de 200, no se recibe una respuesta en tres segundos, o no recibimos ninguna respuesta, reintentamos la solicitud y mantenemos la conexión abierta durante tres segundos. Esto significa que dispones de aproximadamente cinco segundos en dos intentos para responder y recibir la actividad que intentamos enviar a la URL de tu webhook. En caso de que tu servidor no responda o devuelva un error transitorio, reintentaremos durante cinco minutos. Habrá un total de tres reintentos para confirmar la validación. Esto proporciona redundancia y asegura que recibas todos los eventos de webhook. Nota que las suscripciones con reintentos recibirán eventos reintentados para 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 de Actividad de Cuenta.

Cronograma de reintentos

La API de actividad de cuenta reintentará hasta tres veces durante un período de cinco minutos hasta recibir una respuesta 200. Consulte la tabla a continuación para más detalles. Después de aproximadamente cinco minutos, la actividad no se puede reenviar a través de la API de actividad de cuenta. Tendrá que usar otros endpoints de X para recopilar los datos perdidos. Por ejemplo, las APIs de búsqueda se pueden usar para recuperar publicaciones relevantes, retuits, tuits con cita, menciones y respuestas. Los mensajes directos perdidos se pueden recuperar con este endpoint.

Cronograma de reintentos


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

Estructura del objeto de datos de actividad de cuenta

Objeto	Detalles
for_user_id	Identifica al usuario suscrito al que se relaciona el evento.
is_blocked_by	(condicional) Solo se muestra cuando otro usuario menciona a su usuario suscrito. Se incluye si es true, únicamente para eventos de mención de Post.
source	El usuario que realiza la actividad. Por ejemplo, el usuario que sigue, bloquea o silencia es el usuario origen.
target	El usuario al que se aplica la actividad. Por ejemplo, el usuario que es seguido, bloqueado o silenciado es el usuario destino.

Actividades disponibles

Tipo de mensaje	Detalles
tweet_create_events	Payload del estado de Post cuando se realizan cualquiera de las siguientes acciones por o hacia el usuario suscrito: Posts, Retweets, Replies, @mentions, Quote Tweets, Retweet of Quote Tweets.
favorite_events	Estado del 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 silenciar 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 del mensaje directo con el usuario y el destino cuando se envía o recibe un mensaje directo.
direct_message_indicate_typing_events	Evento de indicación 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	Notificación de Posts eliminados para facilitar el cumplimiento normativo.

Ejemplos de payload Consulte los ejemplos de payload a continuación para cada evento de actividad de cuenta descrito en la tabla anterior.

tweet_create_events (Publicaciones, Retuits, Respuestas, Tuits 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": {
				<Objeto de usuario>
			},
			"source": {
				< Objeto de usuario >
			}
		]
	}
}

unfollow_events

{
	"for_user_id": "2244994945",
	"follow_events": [{
			"type": "unfollow",
			"created_timestamp": "1517588749178",
			"target": {
				<Objeto de usuario>
			},
			"source": {
				< Objeto de usuario >
			}
		]
	}
}

eventos_de_bloqueo

{
	"for_user_id": "2244994945",
	"block_events": [{
		"type": "block",
		"created_timestamp": "1518127020304",
		"source": {
			Objeto de usuario
		},
		"target": {
			Objeto de usuario
		}
	}]
}

unblock_events

{
	"for_user_id": "2244994945",
	"block_events": [{
		"type": "unblock",
		"created_timestamp": "1518127020304",
		"source": {
			&lt;Objeto de usuario&gt;
		},
		"target": {
			&lt;Objeto de usuario&gt;
		}
	}]
}

mute_events

{
	"for_user_id": "2244994945",
	"mute_events": [
		{
			"type": "mute",
		  	"created_timestamp": "1518127020304",
			"source": {
				<Objeto de usuario>
			},
			"target": {
				<Objeto de usuario>
			}
		}
	]
}

unmute_events

{
	"for_user_id": "2244994945",
	"mute_events": [
		{
			"type": "unmute",
		  	"created_timestamp": "1518127020304",
			"source": {
				Objeto de usuario
			},
			"target": {
				Objeto de usuario
			}
		}
	]
}

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": "¡Hola Mundo!",
				"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 las-opiniones-son-propias",
			"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 opinions-are-my-own",
			"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

Empresarial La API de Reproducción de Actividad de Cuenta es una herramienta de recuperación de datos que le permite recuperar eventos de hasta cinco días atrás. Debe utilizarse para recuperar datos en escenarios donde su servidor webhook pierde eventos, — ya sea debido a desconexiones que duran más que la ventana de reintento, o para esos escenarios de recuperación ante desastres donde necesita unos días para restaurar su sistema a la normalidad. La API de Reproducción de Actividad de Cuenta se desarrolló para cualquier escenario en el que no logre ingerir actividades durante un período de tiempo. Entrega las 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 rellenado retrospectivo, lo que significa que los eventos solo se reproducirán si se intentó una entrega previa de ellos. La API de Reproducción de Actividad de Cuenta no puede entregar eventos para un período de tiempo anterior al momento de creación de la suscripción.

Uso de la API de Reproducción de Actividad de Cuenta

Si su cuenta está configurada con la funcionalidad de Reproducción, puede realizar solicitudes de manera similar a las que se hacen a la API de Actividad de Cuenta. Es importante tener en cuenta que su solicitud debe especificar el parámetro id del webhook para indicar qué webhook es el que desea reproducir. En otras palabras, una solicitud de Reproducción le pide a la API de Reproducción de Actividad de Cuenta que recupere eventos desde una fecha y hora de inicio hasta una fecha y hora de fin, en función del id del webhook y del id de la aplicación. Tenga en cuenta que se espera la hora UTC. Estas actividades se entregan a través del webhook registrado asociado con dicho id, a una tasa de hasta 2.500 eventos por segundo. También tenga en cuenta que solo puede ejecutarse un trabajo de Reproducción por webhook a la vez, aunque se reproducirán todas las suscripciones que estaban activas durante la fecha y hora especificadas en ese webhook. 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 entregue el minuto final. En ese momento, Reproducción entregará un evento de finalización del trabajo al webhook. Dado que la entrega de actividades se realiza de forma cronológica, si hay pocos o ningún resultado coincidente cerca de la hora de inicio, es probable que transcurra un período de tiempo antes de que se entreguen los primeros resultados.

Limitaciones

Replay está pensado como una herramienta para recuperar fácilmente actividades hasta hace cinco días, pero no proporcionará eventos anteriores a la fecha de creación de la suscripción. Por ejemplo, si hace tres días agregaste una nueva suscripción y ejecutaste un trabajo de Replay con una ventana de cinco días anteriores a hoy, solo recibirías datos para los tres días en que esta nueva suscripción estuvo activa.

Disponibilidad y tipos de datos

Las actividades de la API de Reproducción de Actividad de Cuenta están disponibles durante cinco días a partir del inicio de la solicitud, con nuevos datos que se hacen disponibles aproximadamente 10 minutos después de la creación de una actividad dada. Podrá realizar solicitudes especificando un período de tiempo dentro de esta ventana de cinco días mediante 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 su cuenta se habilitó para el acceso a la API de Reproducción de Actividad de Cuenta el 1 de junio de 2019 a las 3:30 p. m. UTC, no podría usar Replay para recuperar ningún evento anterior a esa fecha y hora. Continúe a la referencia de la API de Reproducción de Actividad de Cuenta

Introducción a la migración

Retiramos los Site Streams, User Streams y la versión beta estándar de los productos Account Activity API - Solo DM en 2018. Si había estado usando esos productos, asegúrese de migrar a la versión premium o empresarial de la Account Activity API. **También hemos retirado los endpoints heredados de Direct Message. Si había estado usando esos endpoints, asegúrese de migrar a los nuevos endpoints de DM, o a la versión premium o empresarial de la Account Activity API. ** Por favor, revise este anuncio para aprender más. Aquí están 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

Tenemos nuevos endpoints y servicios disponibles que proporcionan un acceso similar y, para Direct Messages, cierta funcionalidad adicional:

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

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

Guía de migración de Account Activity API para aquellos que migran de User Streams y Site Streams a nuestro nuevo servicio basado en webhooks
Guía de migración de Direct Message para aquellos que migran entre endpoints REST de Direct Message

Adicionalmente, tenemos una serie de videos sobre la Account Activity API y cómo empezar. Y, finalmente, tenemos ejemplos de código para ampliar su comprensión y ayudarlo a empezar rápidamente:

El Account Activity Dashboard es una aplicación web de muestra en Node.js con scripts de ayuda para empezar con la Account Activity API.
SnowBot es un chatbot de muestra que utiliza la Account Activity API y los endpoints REST de Direct Message. Está escrito en Ruby, utiliza el framework de aplicación web Sinatra y se despliega en Heroku.

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

A partir del 23 de agosto de 2018, retiramos tanto Site Streams como User Streams. Asegúrese de migrar a la Account Activity API. Por favor, revise este anuncio para obtener más información. Esta guía está diseñada para ayudarlo a migrar de las APIs de legado de User Streams y Site Streams a su reemplazo, la Account Activity API. A continuación, encontrará un resumen de los cambios, una lista de nuevas características, así como diferencias clave y consideraciones para facilitar la transición. Para obtener orientación en la migración desde los endpoints básicos de DM, por favor refiérase a la Guía de migración de mensajes directos.

Resumen de cambios

La API de Actividad de Cuenta le proporcionará eventos para cuentas autenticadas y suscritas mediante webhooks, en lugar de una conexión de streaming como en User Streams y Site Streams.

APIs deprecadas

GET user GET site (incluyendo 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 reemplazo

API de Actividad de Cuenta Empresarial - Todas las Actividades

Diferencias y consideraciones de migración

Formato de la API: La nueva API de actividad de cuenta funciona de manera diferente a User Streams y Site Streams. Tendrá que modificar su aplicación web para recibir datos mediante webhooks. Puede encontrar más información sobre webhooks aquí. Datos disponibles: Otra diferencia clave que notará es en cuanto a los datos entregados. X ya no enviará eventos de las personas que sigue en X (también conocido como su línea de tiempo de inicio). Este fue un cambio intencional y no es algo que planeamos cambiar en el futuro. Confiabilidad: A diferencia del streaming, los webhooks permiten confirmar la entrega y reintentar las actividades POST que no lleguen a la URL del webhook. Esto ofrece mayor garantía de que la app reciba todas las actividades aplicables, incluso en caso de desconexiones breves o periodos de inactividad.

Nuevas características

La API de Actividad de Cuenta ofrece muchas nuevas características, destacando especialmente que los datos ahora se entregan mediante webhooks en lugar del streaming. Los webhooks ofrecen muchos beneficios en comparación con el streaming, pero los más destacados son la velocidad y la confiabilidad. La API le enviará datos en forma de eventos JSON a medida que estén disponibles y ya no necesitará mantener una conexión activa ni consultar el endpoint periódicamente. Esto reduce la necesidad de características de redundancia y aumenta la eficiencia en general. Para obtener más información sobre webhooks, consulte la documentación técnica.

Gestión de suscripciones de usuario

La API de Actividad de Cuenta permite múltiples suscripciones para un solo webhook registrado. Esto permite que las actividades de múltiples suscripciones de usuario se entreguen en la misma ubicación, similar a la arquitectura de Site Streams, mediante webhooks. Esto significa que puede rastrear las suscripciones, en la medida en que se refieren a sus límites de suscripción, de manera independiente de la conexión del webhook. Esto también permite escalabilidad desde solo una o unas pocas suscripciones hasta miles de suscripciones para un solo webhook.

Cómo migrar

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

Paso 1: Decida sobre un paquete Dependiendo de cómo esté operando actualmente con User Streams o Site Streams, debe considerar migrar a la versión empresarial o premium de la API de Account Activity. Considere el número de aplicaciones o usuarios autorizados que está soportando actualmente y ajuste el nivel de acuerdo con el volumen y la confiabilidad necesarios. Al decidir el paquete que mejor se adapte a sus necesidades, algunas cosas que vale la pena considerar son:

Número de webhooks necesarios
Suscripciones/usuarios autorizados actuales/proyectados gestionados en su aplicación
Número actual de aplicaciones cliente de X
El nivel de soporte que preferiría de X (soporte de foro o soporte gestionado empresarial nivel 1:1)
Precio de cada paquete

Paso 2: Verifique la configuración de su App de X en el portal de desarrolladores La App de X actualmente utilizada para User Streams o Site Streams estará listada para el usuario propietario dentro del portal de desarrolladores. Esta App de X también se puede usar para la API de Account Activity para conservar los usuarios autorizados de esa aplicación. También se puede crear una nueva app, y los usuarios pueden reautorizarse para esta nueva app si lo desea. Si está creando una nueva app en nombre de un negocio, se recomienda que la cree con una cuenta corporativa de X @handle.

Habilite “Leer, Escribir y Acceder a mensajes directos” en la pestaña de permisos de la página de su App de X. *Tenga en cuenta que cambiar estos ajustes no es retroactivo; cualquier usuario autorizado mantendrá los ajustes de autorización del momento en que fueron autorizados. Si un usuario no le ha dado ya acceso de lectura, escritura y mensajes directos, necesitará que ese usuario reautorice su aplicación.
Si no está familiarizado con Inicio de sesión con X y cómo funcionan los contextos de usuario con la X API, revise Obtención de tokens de acceso.
Genere tokens de acceso para el propietario de la App de X en la parte inferior de la pestaña “Claves y tokens”. En esta misma pestaña, tome nota de su Clave de consumidor, Secreto de consumidor, Token de acceso y Secreto de token de acceso. Los necesitará para usar la API.
Genere un token bearer usando su Clave de consumidor y Secreto de consumidor para métodos de API solo de aplicación.

Paso 3: Configuración y personalización de sus webhooks

Cree una app web con un endpoint para usar como su webhook y recibir eventos (p. ej. https://your_domain.com/webhook/twitter o https://webhooks.your_domain.com).
Use su Clave de consumidor, Secreto de consumidor, Token de acceso y Secreto de token de acceso al crear su webhook. Tenga en cuenta que su endpoint debe devolver una respuesta JSON con un response_token que es un hash HMAC SHA-256 codificado en base64 creado a partir del crc_token y el Secreto de consumidor de su app.
Revise la documentación de Protegiendo webhooks prestando especial atención a los requisitos de Verificación de respuesta de desafío (CRC).
Asegúrese de que su webhook soporte solicitudes POST para eventos entrantes y solicitudes GET para el CRC.
Asegúrese de que su webhook tenga baja latencia (<3 segundos para responder a solicitudes POST)

Paso 4: Valide la configuración de su webhook

Las APIs de webhooks protegerán sus webhooks de dos maneras:

- Requerir verificaciones de respuesta de desafío para validar que el propietario del webhook es el propietario de la app web. - Un encabezado de firma en cada solicitud POST para que su app web valide la fuente.

Para verificar que usted es tanto el propietario de la app web como de la URL del webhook, X realizará una Verificación de respuesta de desafío (CRC), que no debe confundirse con una verificación de redundancia cíclica.
Se enviará una solicitud GET con un parámetro llamado crc_token a su URL de webhook. Su endpoint debe devolver una respuesta JSON con un response_token que es un hash HMAC SHA-256 codificado en base64 creado a partir del crc_token y el Secreto de consumidor de su app.
El crc_token cambiará en cada solicitud CRC entrante. El crc_token debe usarse como el mensaje en el cálculo, donde su Secreto de consumidor es la clave.
En caso de que la respuesta sea inválida, los eventos dejarán de enviarse al webhook registrado.

Paso 5: Cree suscripciones para cada usuario autorizado de User Streams o Site Streams Convirtiendo a la API de Account Activity desde User Streams:

Genere una lista de sus suscripciones actuales de usuarios en User Streams
Configure sus nuevas suscripciones de Account Activity API usando la solicitud: POST account_activity/all/:env_name/subscriptions
Confirme sus suscripciones de Account Activity API usando la solicitud: _GET account_activity/all/:env_name/subscriptions/list _

Convertir a la Account Activity API desde Site Streams: (usando streams de control):

Genere una lista de sus suscripciones actuales en Site Streams usando la solicitud: GET /1.1/site/c/:stream_id/info.json
Configure sus nuevas suscripciones de Account Activity API usando la solicitud: POST account_activity/all/:env_name/subscriptions
Confirme sus suscripciones de Account Activity API usando la solicitud: _GET account_activity/all/:env_name/subscriptions/list _

Registrar un webhook y crear suscripciones (no migrando desde Site Streams o User Streams)

Registre la URL de su webhook con su App usando POST webhooks y reciba un webhook_id.
Use el webhook_id devuelto para agregar suscripciones de usuarios con POST webhooks/:webhook_id/subscriptions/all.

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

Hemos creado una App de ejemplo para agilizar las pruebas de la Account Activity API:

Descarga la aplicación de ejemplo Account Activity Dashboard aquí (usa Node.js)
Sigue las instrucciones del README para instalar y ejecutar la App
Una vez que la aplicación esté en ejecución, puedes usar la interfaz para configurar fácilmente tu webhook y crear una nueva suscripción

Actividades disponibles

Tipo de mensaje	Detalles
tweet_create_events	Payload del estado de publicación cuando se realicen cualquiera de las siguientes acciones por o hacia el usuario suscrito: Publicaciones, Retuits, Respuestas, @menciones, Tuits citados
favorite_events	Estado del evento de favorito (me gusta) con el usuario y el objetivo.
follow_events	Evento de seguimiento con el usuario y el objetivo.
block_events	Evento de bloqueo con el usuario y el objetivo.
mute_events	Evento de silenciamiento con el usuario y el objetivo.
direct_message_events	Estado del mensaje directo con el usuario y el objetivo.
direct_message_indicate_typing_events	Evento de indicación de escritura en mensaje directo con el usuario y el objetivo.
direct_message_mark_read_events	Evento de marcado como leído en mensaje directo con el usuario y el objetivo.

Tipos de mensajes de streaming obsoletos


Líneas en blanco	Las líneas en blanco ya no se entregarán en la Account Activity API, ya que se usaban como mensajes keep-alive en User Streams y Site Streams.
Avisos de límite	Los avisos de límite ya no se enviarán a un webhook específico. En su lugar, los usuarios pueden llamar a la API para obtener el uso actual de los handles disponibles. Esto se incluirá en el Portal de desarrolladores en algún momento en el futuro.
Mensajes de desconexión	Los avisos de desconexión ya no serán necesarios, ya que los webhooks no dependen de una conexión activa.
Advertencias de STALL	Las advertencias de STALL ya no serán necesarias, ya que los webhooks no dependen de una conexión activa capaz de manejar un gran número de mensajes entrantes.
Lista de amigos	Las listas de amigos ya no se enviarán de manera proactiva. Ahora habrá un endpoint REST para obtener esta información.

Tipos de eventos depreciados


Descripción	Nombre del evento	Fuente	Objetivo	Objeto objetivo
El usuario elimina una publicación	delete	Usuario actual	Usuario actual	Post
El usuario seguido elimina una publicación	delete	Usuario seguido	Usuario seguido	Post
El usuario quita de favoritos una publicación	unfavorite	Usuario actual	Autor de la publicación	Post
Una publicación del usuario se quita de favoritos	unfavorite	Usuario que quita de favoritos	Usuario actual	Post
El usuario deja de seguir a alguien	unfollow	Usuario actual	Usuario seguido	Null
El usuario crea una lista	list_created	Usuario actual	Usuario actual	List
El usuario elimina una lista	list_destroyed	Usuario actual	Usuario actual	List
El usuario edita una lista	list_updated	Usuario actual	Usuario actual	List
El usuario agrega a alguien a una lista	list_member_added	Usuario actual	Usuario agregado	List
El usuario es agregado a una lista	list_member_added	Usuario que agrega	Usuario actual	List
El usuario retira a alguien de una lista	list_member_removed	Usuario actual	Usuario retirado	List
El usuario es retirado de una lista	list_member_removed	Usuario que retira	Usuario actual	List
El usuario se suscribe a una lista	list_user_subscribed	Usuario actual	Propietario de la lista	List
Alguien se suscribe a la lista del usuario	list_user_subscribed	Usuario que se suscribe	Usuario actual	List
El usuario se da de baja de una lista	list_user_unsubscribed	Usuario actual	Propietario de la lista	List
Alguien se da de baja de la lista del usuario	list_user_unsubscribed	Usuario que se da de baja	Usuario actual	List
El usuario actualiza su perfil	user_update	Usuario actual	Usuario actual	Null
El usuario actualiza su estado protegido	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 habías estado usando esos endpoints, asegúrate de migrar a los nuevos endpoints de Mensajes Directos o a la API de Actividad de Cuenta. Por favor, revisa este anuncio para obtener más información. Esta guía está diseñada para ayudarte a migrar de las API 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 características, y diferencias clave y consideraciones para facilitar la transición. Los nuevos endpoints de Mensajes Directos están disponibles ahora para todos los desarrolladores. Para obtener orientación en la migración de User Streams o Site Streams, consulta la guía de migración a la API de Actividad de Cuenta.

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

Resumen de cambios

Si aún utilizas los siguientes endpoints de MD, deberás migrar a los endpoints más recientes.

Endpoint obsoleto	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 soportan una serie de nuevas capacidades y proporcionan un acceso mejorado a los Mensajes Directos anteriores. Las nuevas funciones incluyen:

Soporte para adjuntos multimedia (imágenes, GIF y vídeos).
Capacidad para solicitar respuestas estructuradas a los usuarios con una lista de opciones predefinida.
Hasta 30 días de acceso a Mensajes Directos anteriores.

Para una lista completa de nuevas funciones de Mensajes Directos y endpoints adicionales nuevos de la API, consulte la documentación técnica.

Diferencias y consideraciones para la migración

Los nuevos endpoints de la API se comportan de forma muy diferente a sus predecesores. Limitarse a actualizar las URL de los endpoints provocará errores en su aplicación. Tenga en cuenta lo siguiente al actualizar su aplicación para la migración.

Nuevo objeto de mensaje directo

Lo primero que probablemente notará es la nueva estructura del objeto de mensajes directos. Esta nueva estructura del objeto de creación de mensaje se ha introducido para admitir nuevas capacidades como Respuestas rápidas y Adjuntos. El nuevo objeto también contiene un objeto de usuario más reducido y condensado. Su aplicación deberá actualizarse para tener en cuenta esta nueva estructura del objeto al analizarla y, potencialmente, en los modelos de datos o el almacenamiento. Para descripciones de cada propiedad, consulte la documentación completa del objeto de creación de mensaje. Ejemplo de objeto de creación de mensaje

{
      "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": "Pájaro Azul",
          "entities": {
            "hashtags": [],
            "symbols": [],
            "urls": [],
            "user_mentions": [],
          },
          "quick_reply_response": {
            "type": "options",
            "metadata": "external_id_2"
          },
          "attachment": {
            "type": "media",
            "media": {
             ...
            }
          }
        }
      }

Resumen

Estructura completamente nueva del objeto de mensaje directo.
Objeto de usuario condensado.
Nueva información proporcionada (respuestas rápidas, adjuntos, etc.).

Envío de Mensajes Directos

POST direct_messages/events/new es un reemplazo directo para el envío de Mensajes Directos. La diferencia más significativa de este endpoint es que toda la información ahora se envía como JSON en el cuerpo de la solicitud POST, en lugar de 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": "¡Hola mundo!"}}}}'

Nota 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 generando 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 OAuth ya lo tienen en cuenta. Si estás utilizando twurl, asegúrate de usar al menos la versión 0.9.3.

Resumen

El mensaje se define en el cuerpo del 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.

Recuperación de mensajes directos

La recuperación de mensajes directos pasados ahora se realiza mediante un único punto final de la API: GET direct_messages/events/list. La diferencia principal con este nuevo punto final 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. No obstante, si solo buscas mensajes enviados o recibidos, deberás procesar la respuesta a posteriori consultando la propiedad sender_id. La paginación ahora se basa en un valor de cursor en lugar del ID de un mensaje directo. Cada respuesta incluye una propiedad cursor. GET direct_messages/events/list devuelve hasta 30 días de mensajes pasados, independientemente de cuántos mensajes haya en los últimos 30 días. Si no se devuelve un cursor, no hay más mensajes disponibles. El método para acceder a mensajes directos individuales mediante 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 los mensajes directos ahora se realiza mediante webhooks con la API de actividad de cuenta. Para obtener orientación sobre la migración desde User Streams o Site Streams, consulta la guía de migración a la API de actividad de cuenta para más información.

Resumen

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

Eliminación de Mensajes Directos

Ahora se pueden eliminar los Mensajes Directos con DELETE direct_messages/events/destroy. La interfaz es en gran medida la misma y requiere el id del mensaje que se desea eliminar. La diferencia clave es que el endpoint ahora 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 en cuyo contexto se realizó la acción. Otros participantes de la conversación aún pueden acceder al Mensaje Directo.

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 no ha cambiado.

**¿Tienes preguntas sobre la migración 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 utiliza webhooks, lo que significa que, a diferencia de las APIs de streaming, no necesitamos que mantengas una conexión abierta para enviarte información. Los webhooks también difieren de las REST APIs porque no tienes que hacernos consultas cientos de veces cada 15 minutos para obtener los datos que te interesan. Esto mejora la eficiencia entre un usuario y tu App, ya que entrega los datos cuando suceden. La Account Activity API tiene varias ventajas:

Velocidad: entregamos 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 que entrega la API incluyen Posts, @mentions, respuestas, Retweets, Quote Tweets, Retweets de Quote Tweets, favoritos, Mensajes Directos enviados, Mensajes Directos recibidos, follows, blocks, mutes.
Escala: recibes todas las actividades de una cuenta que administras sin estar limitado por límites de frecuencia ni topes de eventos.

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

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

¿Hay alguna forma de recuperar datos si nuestro sistema se cae por un período de tiempo? Con los niveles de pago de la Account Activity API (Premium de pago y Empresarial), 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 7 días. Sugerimos que uses tus diferentes webhooks, o entornos, como herramienta de redundancia junto con la Account Activity Replay API para asegurarte de no perder ninguna actividad si uno de tus sistemas se cae. ¿Qué autenticación debo usar con la Account Activity API? Los métodos de autorización requeridos para la 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 verificación de desafío-respuesta (CRC)? La verificación de respuesta al desafío (CRC) 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 máximo de 3 segundos para mantener la validación. Visita nuestra página Securing webhooks para más detalles. ¿Hay algo que invalidaría inmediatamente mi URL de webhook? Si ocurre uno de los siguientes casos, marcaremos inmediatamente tu webhook como no válido:

El servidor responde a un CRC con un token incorrecto. En este caso, nuestro sistema no volverá a intentar enviarte la actividad.
La URL del webhook tiene un certificado incorrecto configurado. En este caso, nuestro sistema no volverá a intentar enviarte la actividad.
Tu servidor devuelve un código de respuesta que no sea 2XX, 4XX o 5XX.
Especificas el uso de gzip sin enviarlo realmente.
No especificas el uso de gzip, pero 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 un Post, 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 hago una suscripción a mi webhook, ¿puedo reemplazar la parte /all/ del siguiente endpoint con otros objetos de datos de actividad de cuenta 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 el estado actual, solo tenemos disponible el producto /all/. ¿Existe 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 hay manera de “filtrar” las actividades de Mensajes Directos para esta API. ¿Existe una versión gratuita de la Account Activity API? Sí, ofrecemos la versión sandbox como un nivel Gratis. Nuestra opción sandbox está limitada a un único webhook con un máximo de 15 suscripciones. Puedes leer más sobre la opción sandbox en nuestra documentación. ¿Es posible usar la Account Activity API para obtener Retweets de Posts 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á un payload de tweet_create_event: Si el usuario de la suscripción realiza cualquiera de las siguientes acciones:

Crea un Post
Hace Retweet
Responde a un Post

Si otro usuario:

@menciona al usuario de la suscripción
Cita un Tweet creado por el usuario de la suscripción

Nota: La Account Activity API solo entrega eventos cuando el usuario de la suscripción 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 fue 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, con el valor “true” o “false”. Este campo solo se expondrá en menciones de Post. Empresarial ¿Cómo puedo añadir mi App a una allowlist o comprobar si mi App ya está en la allowlist? Para gestionar las apps de X que agregaste a una lista de permitidos para el acceso mediante las API Empresariales, comunícate con tu gerente de cuenta y proporciona el id de tu app. Puedes encontrar el id de tu app en la página “Apps” del Portal de desarrolladores. 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, pero no tres en cada app. ¿Puedo especificar qué tipos de eventos se volverán a entregar usando la Account Activity Replay API? No se pueden especificar los tipos de eventos a reproducir. Se volverán a entregar todos los eventos enviados durante la ventana de fecha y hora indicada. ¿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 trabajo de Replay para el mismo período y así intentar la reentrega de cualquier evento de Replay omitido. ¿Qué debo hacer cuando recibo un evento de finalización con éxito parcial? Sugerimos tomar nota de las marcas de tiempo de los eventos recibidos y solicitar otro trabajo de Replay para los eventos que faltaron. ¿Cuántos trabajos de la Account Activity Replay API puedo tener en ejecución al mismo tiempo? Solo puede estar en ejecución un trabajo de la Account Activity Replay API por webhook a la vez. ¿Cómo puedo diferenciar los eventos de la 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, pueden diferenciarse de los eventos de producción en tiempo real según 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 omitió o perdió? Una actividad está disponible para reentrega aproximadamente 10 minutos después de su creación.

Guía para solucionar errores

Código 32

Este error generalmente indica que algo está mal formado en la solicitud, los encabezados, la Autenticación o la URL que está especificando. No es un error del Account Activity API; es un error de Autenticación y X no está recibiendo la configuración adecuada de OAuth o la URL.

Empresarial - Asegúrese de que las consumer keys y los access tokens que está usando pertenezcan a una App de X registrada para el uso de productos Empresarial. Si no tiene sus consumer keys y access tokens, o necesita agregar su App de X a la allowlist, comuníquese con su account manager.
Si se autentica con contexto de usuario, asegúrese de haber autorizado su solicitud correctamente con los oauth_nonce, oauth_signature y oauth_timestamp adecuados.
Asegúrese de que sus access tokens tengan el nivel de permiso adecuado.
- En la pestaña ‘Keys and tokens’ del app dashboard, asegúrese de que sus access tokens tengan el nivel de permiso ‘Read, write, and direct messages’ permission level.
- Si el nivel de permiso de los tokens está configurado por debajo de esto, vaya a la pestaña ‘Permissions’, ajuste el permiso de acceso a ‘Read, write, and direct messages’ y luego regenere sus access tokens y secret desde la pestaña ‘Keys and tokens’.
Asegúrese de que su URL esté formada correctamente.
- Tenga en cuenta que :env_name distingue entre mayúsculas y minúsculas.

Código 200 - Prohibido

Premium - Asegúrate de tener una cuenta de desarrollador aprobada antes de intentar hacer 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.
Empresarial - Asegúrate de que tu gestor de cuenta te haya habilitado el acceso a la Account Activity API.
Asegúrate de haber configurado correctamente el URI. Este error puede producirse si ingresaste un URI incorrecto en tu solicitud.

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

Asegúrese de estar usando https.
Es posible que la URL del webhook esté malformada.
Obtenga más información sobre cómo configurar la URL del webhook en la sección Develop webhook consumer app de la página Getting started with webhooks.

Código 214 - Latencia alta en la solicitud CRC mediante GET. Tu webhook debe responder en menos de 3 segundos.

Esto indica que tu servidor está tardando demasiado. Asegúrate de responder al CRC en un máximo de 3 segundos.

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

Su servidor no está disponible. Asegúrese de que esté en ejecución correctamente.

Código 214 - Se han creado demasiados recursos.

Empresarial - Ya has utilizado todos tus webhooks. Usa el endpoint GET webhooks con cada una de tus Apps registradas para identificar dónde están distribuidos tus webhooks.

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

La App que está utilizando con la API no tiene establecido el nivel de permiso adecuado para su access token y access token secret. Vaya a la pestaña “Keys and tokens” en el panel de X apps y verifique los niveles de permiso asignados a su access token y access token secret. Si está configurado en algo distinto de “Read, write and Direct Messages”, deberá ajustar la configuración en la pestaña “Permission” y regenerar su access token y access token secret para aplicar la nueva configuración.
Alternativamente, está intentando registrar un webhook usando autenticación solo de App, lo cual no es compatible. Autentíquese con contexto de usuario, como se indica en las secciones de referencia de la API para registrar un webhook para Enterprise Account Activity API.

Índice de referencia de la Account Activity API


Propósito	Empresarial
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 App a los eventos de una cuenta	POST webhooks/:webhook_id/subscriptions/all
Devuelve el recuento de suscripciones activas	GET subscriptions/count
Comprueba si un webhook está suscrito a una cuenta	GET webhooks/:webhook_id/subscriptions/all
Devuelve una lista de suscripciones activas	GET webhooks/:webhook_id/subscriptions/all/list
Elimina el webhook	DELETE webhooks/:webhook_id
Desactiva una suscripción con OAuth de 3 partes (OBSOLETO)	DELETE webhooks/:webhook_id/subscriptions/all
Desactiva una suscripción con OAuth solo de aplicación	DELETE webhooks/:webhook_id/subscriptions/:user_id/all.json
Reentrega actividades a un webhook	POST replay/webhooks/:webhook_id/subscriptions/all

API de actividad de cuentas Empresarial

POST account_activity/webhooks

Registra una nueva URL de webhook para el contexto de la App indicado. La URL se validará mediante una solicitud CRC antes de guardarla. Si la validación falla, se devuelve un mensaje de error detallado al solicitante. La cantidad de webhooks permitidos está determinada por el plan de facturació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í (contexto de usuario: todos los tokens de consumidor y de acceso)
Sujeto a límite de tasa	Sí
Solicitudes por ventana de 15 min (autenticación de usuario)	15
Compatibilidad con ediciones de Tweet	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 de fundamentos de ediciones de Tweet para más detalles.

Parámetros


url (obligatorio)	URL codificada para el 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 App proporcionada
403	Se produjo un error en tu solicitud. Consulta la sección de mensajes de error a continuación.

Respuesta de ejemplo: correcto

_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 no válido o formato de respuesta JSON.
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 (p. ej., 404, 500, etc.).

HTTP 403

    {
      "errors": [
        {
          "code": 214,
          "message": "Se han creado demasiados recursos."
        }
      ]
    }

GET account_activity/webhooks

Devuelve todas las URL y sus estados de la App indicada. Marcamos una URL como no válida si falla la verificación diaria. Para volver a habilitarla, 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 - token de portador)
Límite de tasa	Sí
Solicitudes por 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'

Respuesta de ejemplo

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 tiene acceso a este recurso.

PUT account_activity/webhooks/:webhook_id

Activa la verificación de respuesta al desafío (CRC) para la URL del webhook indicado. Si la verificación se realiza correctamente, devuelve 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 uso	Sí
Solicitudes por ventana de 15 minutos (autenticación de usuario)	15

Parámetros


webhook_id (obligatorio)	id del webhook. Definido 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 a una App de X diferente.
214	La URL del webhook no cumple los requisitos.
214	La URL del webhook no cumple los requisitos. Token CRC no válido o formato de respuesta JSON no válido.
214	Latencia alta 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 (p. ej., 404, 500, etc.).

POST account_activity/webhooks/:webhook_id/subscriptions/all

Suscribe la App proporcionada a todos los eventos del contexto de usuario indicado para todos los tipos de mensajes. Tras la activación, todos los eventos del usuario solicitante se enviarán al webhook de la App mediante una solicitud POST. Las suscripciones están actualmente limitadas según la configuración de su cuenta. Si necesita agregar más suscripciones, póngase en contacto con su gestor 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 etapas: clave de consumidor incluida en la lista de permitidos y token de acceso del usuario suscriptor)
Sujeto a límite de tasa	Sí
Solicitudes por ventana de 15 min (autenticación de usuario)	500

Parámetros


webhook_id (obligatorio)	id 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: éxito

HTTP 204 SIN CONTENIDO

{}

Mensajes de error

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

GET account_activity/subscriptions/count

Devuelve el número de suscripciones que actualmente están activas en tu cuenta. Ten en cuenta que el endpoint /count requiere OAuth de solo aplicación, por lo que debes realizar las solicitudes con un token bearer en lugar de en 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: token de portador)
Sujeto a limitación de tasa	Sí
Solicitudes por ventana de 15 minutos (autenticación de App)	15

Códigos de respuesta HTTP


Código	Mensaje
200	Correcto. Se devolverá el recuento de suscripciones para el webhook solicitado.
401	Su App 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/subscriptions/count.json
     --header 'authorization: Bearer TOKEN'

Respuesta de ejemplo: correcto

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.

HTTP 401

    {
      "errors": [
        {
           "code": 32,
          "message": "No se pudo autenticarte."
        }
      ]
    }

GET account_activity/webhooks/:webhook_id/subscriptions/all

Permite determinar si una configuración de webhook está suscrita a los eventos del usuario indicado. Si el contexto del usuario indicado tiene una suscripción activa con la App indicada, devuelve 204 OK. Si el código de respuesta no es 204, el usuario no tiene una suscripción activa. Consulta a continuación el código de respuesta HTTP y los mensajes de error 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 la respuesta	JSON
Requiere autenticación	Sí (OAuth de 3 fases: clave de consumidor autorizada y token de acceso del usuario suscriptor)
Sujeto a límite de uso	Sí
Solicitudes por ventana de 15 min (autenticación de usuario)	500

Parámetros


webhook_id (obligatorio)	id del 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_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. Tenga en cuenta que el endpoint /list requiere OAuth solo para la App, por lo que las solicitudes deben realizarse usando un token bearer en lugar de 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 App: token bearer)
Límite de uso	Sí
Solicitudes por ventana de 15 min (autenticación de App)	50

Parámetros


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

Códigos de respuesta HTTP

Código	Mensaje
200	Correcto. Se devolverá una lista de suscripciones para el webhook solicitado.
401	Su App 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/webhooks/:WEBHOOK_ID/subscriptions/all/list.json —header ‘authorization: Bearer TOKEN’

Respuesta de ejemplo: correcto

HTTP 200

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

Mensajes de error

Código	Mensaje
32	No se pudo autenticar.

HTTP 401

    {
      "errors": [
        {
           "code": 32,
          "message": "No se pudo autenticarte."
        }
      ]
    }

DELETE account_activity/webhooks/:webhook_id

Elimina el webhook de la configuración de la App indicada. El id del webhook se puede obtener haciendo 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 por ventana de 15 min (autenticación de usuario)	15

Parámetros


webhook_id (obligatorio)	id 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 para el contexto de usuario y la App suministrados. Tras la desactivación, ya no se enviarán eventos del usuario solicitante 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 fases: clave de consumidor autorizada y token de acceso del usuario suscrito)
Sujeto a límites de tasa	Sí
Solicitudes por ventana de 15 min (autenticación de usuario)	500

Parámetros


webhook_id (obligatorio)	id 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 el id de usuario especificados. Tras la desactivación, todos los eventos del usuario que realiza la solicitud dejarán de enviarse a la URL del webhook. Ten en cuenta que este endpoint requiere OAuth solo de aplicación, por lo que las solicitudes deben realizarse con un token Bearer en lugar del 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 - token Bearer)
Sujeto a límites de tasa	Sí
Solicitudes por ventana de 15 min	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 SIN CONTENIDO

Mensajes de error

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

API de reproducción

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 concurrente. Nota: realizamos un CRC antes de entregar los eventos de reproducción.


Método de solicitud	HTTP POST
URL	/1.1/account_activity/replay/webhooks/:webhook_id/subscriptions/all.json?from_date=yyyymmddhhmm&to_date=yyyymmddhhmm
Formato de respuesta	JSON
Requiere Autenticación	Sí (solo aplicación: token bearer)
Límite de frecuencia	5 solicitudes cada 15 minutos. Actualmente no existe un máximo en la cantidad de trabajos de reproducción que se pueden solicitar.
from_date	La marca de tiempo UTC más antigua (inicial) desde la cual se proporcionarán los eventos; debe estar en el formato ‘yyyymmddhhmm’. La marca de tiempo tiene granularidad de minuto y es inclusiva (p. ej., 12:00 incluye el minuto 00). Los tiempos válidos 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 ~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 minuto y es exclusiva (p. ej., 12:30 no incluye el minuto 30 de la hora). Los tiempos válidos 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 distintas de 200, debes resolver el error e intentarlo de nuevo.

Estado	Texto	Código de error	Descripción	Mensaje
202	Accepted	N/D	La solicitud se realizó correctamente y se enviarán las actividades.	N/D
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 no válido.	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ó debido a la autenticación de 3-legged proporcionada.	Método de autenticación no válido. Utiliza autenticación solo para aplicaciones.
401	Unauthorized	61	El cliente no tiene permiso para solicitar este método.	El cliente no tiene permiso para solicitar este método.
403	Forbidden	200	El cliente no tiene una cuenta empresarial con Replay habilitado.	Se requiere una cuenta empresarial del Account Activity API con replay. Confirma que tienes una cuenta empresarial y que replay está habilitado.
404	Not Found	34	webhook_id inexistente; discrepancia entre webhook_id y application_id.	El webhook no existe o está asociado a una App de X diferente.
409	Conflict	355	Hay una solicitud en curso y deberá finalizar su procesamiento 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 superó el 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. Vuelve a intentarlo usando un patrón de backoff exponencial.

Mensaje “Job completed successfully”

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

{
  "replay\_job\_status": {
    "webhook_id": "1234577122340233217",
    "job_state": "Complete",
    "job\_state\_description": "Trabajo completado con éxito"
    "job_id": "1095098195724558337"
  }
}

Mensaje “Job failed to complete”

Si tu job no se completa correctamente, mostraremos el siguiente mensaje para recomendarte reintentar 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": "Incompleto",
    "job\_state\_description": "El trabajo no pudo entregar todos los eventos. Reintente su trabajo de reproducción",
    "job_id": "1093226942650736640"
  }
}

Ejemplo de solicitud de 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'

Respuesta de ejemplo

HTTP 202

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

Descripción general

Posts

Usuarios

Mensajes Directos

Me gusta

Listas

Espacios

Comunidades

Notas de la comunidad

Tendencias

Multimedia

Actividad de X

Uso

Conexiones de streaming

Cumplimiento normativo

Empresarial v2

Flujos de “Me gusta”

GNIP 2.0

​Serie de videos

​Resumen de características

​Administrar webhooks y usuarios suscritos

​Administrar un webhook:

​Gestión de usuarios suscritos:

​Artículos referenciados

​Un recorrido en video de la API de Actividad de Cuenta

​Primeros pasos con webhooks

​1. Crear una app de X.

​2. Obtener acceso a la API de Actividad de Cuenta

​3. Desarrollar una aplicación web consumidora de webhooks

​4. Validar la configuración

​Proteger webhooks

​Verificaciones de desafío-respuesta

​La solicitud CRC se realizará:

​Requisitos de respuesta:

​Bibliotecas HMAC específicas por lenguaje:

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

​Ejemplo de respuesta JSON:

​Otros ejemplos:

​Validación opcional de la firma en el encabezado

​Directrices de seguridad adicionales

​Bloques de red agregados de X

​Configuraciones de servidor recomendadas

​Gestión de webhooks y suscripciones

​Creación y cambio de webhooks

​Endpoints para la gestión de la configuración de webhooks:

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

​Agregar & eliminar suscripciones de usuario

​Endpoints de gestión de suscripciones

​Reintentos

​¿Qué son los reintentos?

​Cronograma de reintentos

​Cronograma de reintentos

​Estructura del objeto de datos de actividad de cuenta

​tweet_create_events (Publicaciones, Retuits, Respuestas, Tuits citados)

​tweet_create_events (@menciones)

​favorite_events

​follow_events

​unfollow_events

​eventos_de_bloqueo

​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 la API de Reproducción de Actividad de Cuenta

​Limitaciones

​Disponibilidad y tipos de datos

​Introducción a la migración

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

​Resumen de cambios

​APIs deprecadas

​APIs de reemplazo

​Diferencias y consideraciones de migración

​Nuevas características

​Gestión de suscripciones de usuario

​Cómo migrar

Serie de videos

Resumen de características

Administrar webhooks y usuarios suscritos

Administrar un webhook:

Gestión de usuarios suscritos:

Artículos referenciados

Un recorrido en video de la API de Actividad de Cuenta

Primeros pasos con webhooks

1. Crear una app de X.

2. Obtener acceso a la API de Actividad de Cuenta

3. Desarrollar una aplicación web consumidora de webhooks

4. Validar la configuración

Proteger webhooks

Verificaciones de desafío-respuesta

La solicitud CRC se realizará:

Requisitos de respuesta:

Bibliotecas HMAC específicas por lenguaje:

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

Ejemplo de respuesta JSON:

Otros ejemplos:

Validación opcional de la firma en el encabezado

Directrices de seguridad adicionales

Bloques de red agregados de X

Configuraciones de servidor recomendadas

Gestión de webhooks y suscripciones

Creación y cambio de webhooks

Endpoints para la gestión de la configuración de webhooks:

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

Agregar & eliminar suscripciones de usuario

Endpoints de gestión de suscripciones

Reintentos

¿Qué son los reintentos?

Cronograma de reintentos

Cronograma de reintentos

Estructura del objeto de datos de actividad de cuenta

tweet_create_events (Publicaciones, Retuits, Respuestas, Tuits citados)

tweet_create_events (@menciones)

favorite_events

follow_events

unfollow_events

eventos_de_bloqueo

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 la API de Reproducción de Actividad de Cuenta

Limitaciones

Disponibilidad y tipos de datos

Introducción a la migración

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

Resumen de cambios

APIs deprecadas

APIs de reemplazo

Diferencias y consideraciones de migración

Nuevas características

Gestión de suscripciones de usuario

Cómo migrar

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

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

Actividades disponibles

Tipos de mensajes de streaming obsoletos

Tipos de eventos depreciados

Guía de migración de Mensajes Directos

Resumen de cambios

Nuevas funciones

Diferencias y consideraciones para la migración

Nuevo objeto de mensaje directo

Resumen

Envío de Mensajes Directos

Resumen

Recuperación de mensajes directos

Resumen

Eliminación de Mensajes Directos

Resumen

Preguntas frecuentes