Este endpoint se ha actualizado para incluir metadatos de edición de Publicaciones. Obtén más información sobre estos metadatos en la página de conceptos básicos de “Editar Publicaciones”. Este endpoint se usa a menudo con los endpoints de Mensajes Directos. Hemos lanzado nuevos endpoints v2 de Mensajes Directos. Ten en cuenta que las APIs de Actividad de la Cuenta Enterprise y Premium son compatibles con mensajes uno a uno de v2, pero aún no admiten conversaciones de grupo. Enterprise
La API de Actividad de la Cuenta te permite suscribirte a actividades en tiempo real relacionadas con una cuenta de usuario mediante webhooks. Esto significa que puedes recibir Publicaciones en tiempo real, Mensajes Directos y otros eventos de cuenta desde una o varias de tus cuentas propias o a las que estés suscrito, a través de una única conexión.
Recibirás todas las actividades relacionadas que se indican a continuación para cada suscripción de usuario en tu registro de webhook:
| Tipos de actividad | |
|---|
* Publicaciones (del usuario)
* Eliminaciones de Publicaciones (del usuario)
* Menciones @ (del usuario)
* Respuestas (al usuario o del usuario)
* Retweets (del usuario o sobre el usuario)
* Tweets citados (del usuario o sobre el usuario)
* Retweets de Tweets citados (del usuario o sobre el usuario)
* Me gusta (del usuario o sobre el usuario)
* Seguimientos (del usuario o hacia el usuario)
* Dejar de seguir (del usuario) | * Bloqueos (del usuario)
* Desbloqueos (del usuario)
* Silenciamientos (del usuario)
* Reactivaciones de silencio (del usuario)
* Mensajes Directos enviados (por el usuario)
* Mensajes Directos recibidos (por el usuario)
* Indicadores de escritura (para el usuario)
* Confirmaciones de lectura (para el usuario)
* Revocaciones de suscripción (por el usuario) |
| Nivel | Precio | Número de suscripciones únicas | Número de webhooks | Fiabilidad y recuperación de actividad |
|---|
| Enterprise | Contactar con el equipo de ventas | Hasta 500+ | 3+ | Reintentos y Replay |
-
¿Tienes preguntas? ¿Te estás encontrando con errores?
-
Explora nuestro código de ejemplo:
- Enterprise Account Activity API dashboard, una aplicación web en Node que muestra eventos de webhook utilizando el nivel Enterprise de la Account Activity API e incluye la funcionalidad de Replay.
- El SnowBot chatbot, una aplicación web en Ruby creada sobre las APIs empresariales de Account Activity y Direct Message.
Administrar webhooks y usuarios suscritos
Agregar un webhook
Ver un webhook
Eliminar un webhook
Comencemos registrando una nueva URL de webhook para el contexto de la aplicación indicado.La URL se validará mediante una solicitud CRC antes de guardarla. Una vez que hayas registrado un webhook, asegúrate de documentar el ID del webhook, ya que lo necesitarás más adelante.Copia la siguiente solicitud de cURL en tu línea de comandos tras sustituir los siguientes valores:
-
URL
<URL> p. ej. https://yourdomain.com/webhooks/twitter/
-
Consumer key
<CONSUMER_KEY> p. ej. xvz1evFS4wEEPTGEFPHBog
-
Access token
<ACCESS_TOKEN> p. ej. 370773112-GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb
curl --request POST --url 'https://api.x.com/1.1/account_activity/webhooks.json?url=<URL>' --header 'authorization: OAuth oauth_consumer_key="<CONSUMER_KEY>", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="<ACCESS_TOKEN>", oauth_version="1.0"'
Ejecutaremos el siguiente comando, que devuelve todas las URL de webhook registradas y sus estados para la aplicación indicada.Copia la siguiente solicitud de cURL en tu línea de comandos tras sustituir los siguientes valores:
-
Bearer Token
<BEARER_TOKEN> p. ej. AAAAAAAAAAAA0%2EUifi76ZC9Ub0wn...
--request GET --url https://api.x.com/1.1/account_activity/webhooks.json --header
Para eliminar un webhook de la configuración de la aplicación indicada, copia la siguiente solicitud de cURL en tu línea de comandos tras sustituir los siguientes valores:
-
Webhook ID
<:WEBHOOK_ID> p. ej. 1234567890
-
Consumer key
<CONSUMER_KEY> p. ej. xvz1evFS4wEEPTGEFPHBog
-
Access token
<ACCESS_TOKEN> p. ej. 370773112-GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb
--request DELETE --url https://api.x.com/1.1/account_activity/webhooks/<:WEBHOOK_ID>.json --header
Gestión de usuarios suscritos:
Agregar una suscripción
Ver suscripciones
Eliminar una suscripción
Comenzaremos suscribiendo a un usuario para que recibas todos los tipos de evento.Copia la siguiente solicitud cURL en tu línea de comandos después de realizar cambios en lo siguiente:
-
Webhook ID
<:WEBHOOK_ID> p. ej. 1234567890
-
Nombre de la consumer key
<CONSUMER_KEY> p. ej. xvz1evFS4wEEPTGEFPHBog
-
Token de acceso del usuario suscrito
<SUBSCRIBING_USER'S_ACCESS_TOKEN> p. ej. 370773112-GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb
curl --request POST --url https://api.x.com/1.1/account_activity/webhooks/<:WEBHOOK_ID>/subscriptions/all.json --header 'authorization: OAuth oauth_consumer_key="<CONSUMER_KEY>", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="<SUBSCRIBING_USER'S_ACCESS_TOKEN>", oauth_version="1.0"'
Para ver una lista de todas las suscripciones a tipos de actividad para un webhook especificado, copia la siguiente solicitud cURL en tu línea de comandos después de realizar cambios en lo siguiente:
-
Webhook ID
<:WEBHOOK_ID> p. ej. 1234567890
-
Bearer Token
<BEARER_TOKEN> p. ej. AAAAAAAAAAAA0%2EUifi76ZC9Ub0wn...
curl --request GET --url https://api.x.com/1.1/account_activity/webhooks/<:WEBHOOK_ID>/subscriptions/all/list.json --header 'authorization: Bearer <BEARER_TOKEN>'
Después de la desactivación, todos los eventos del usuario solicitante dejarán de enviarse a la URL del webhook.Para desactivar una suscripción desde el contexto del usuario y la aplicación proporcionados, copia la siguiente solicitud cURL en tu línea de comandos después de realizar cambios en lo siguiente:
-
Webhook ID
<:WEBHOOK_ID> p. ej. 1234567890
-
Consumer key
<CONSUMER_KEY> p. ej. xvz1evFS4wEEPTGEFPHBog
-
Token de acceso del usuario suscrito
<SUBSCRIBING_USER'S_ACCESS_TOKEN> p. ej. 370773112-GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb
curl --request DELETE --url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID/subscriptions/all.json --header 'authorization: OAuth oauth_consumer_key="CONSUMER_KEY", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="SUBSCRIBED_USER'S_ACCESS_TOKEN", oauth_version="1.0"'
Un recorrido en video por la Account Activity API
- Registrar un webhook
- Agregar una suscripción de usuario
- Eliminar una suscripción de usuario
- Recibir actividades de cuenta
- Reproducir actividades de cuenta
-
¿Tienes preguntas? ¿Te estás encontrando con errores?
-
Explora nuestro código de ejemplo:
Enterprise
Introducción a los webhooks
- Crea una App de X con una cuenta de desarrollador aprobada en la Consola de desarrollador. Si estás creando la App en nombre de tu empresa, se recomienda que la crees con una cuenta corporativa de X. Para solicitar una cuenta de desarrollador, haz clic aquí.
- Habilita “Read, Write and Access direct messages” en la pestaña de permissions de la página de tu App.
- En la pestaña “Keys and Access Tokens”, toma nota de la Consumer Key (API Key) y del Consumer Token (API Secret) de tu App.
- En la misma pestaña, genera el Access Token y Access Token Secret de tu App. Necesitarás estos Access Tokens para registrar la URL de tu webhook, que es donde X enviará los eventos de cuenta.
- Si no estás familiarizado con X Sign-in y cómo funcionan los contextos de usuario con X API, revisa Obtaining Access Tokens. A medida que vayas agregando cuentas para recibir eventos, las suscribirás usando los Access Tokens de esa cuenta.
- Toma nota del ID numérico de tu App, tal como aparece en la página “Apps” de la Consola de desarrollador. Cuando solicites acceso a Account Activity API, necesitarás este id de la App.
2. Obtener acceso a Account Activity API
3. Desarrollar la aplicación consumidora de webhooks
-
Crea una aplicación web con una URL para usarla como tu webhook para recibir eventos. Este es el endpoint desplegado en tu servidor que escucha los eventos de webhook entrantes de X.
-
Como se describe en nuestra guía de Protección de webhooks, un primer paso es escribir código que reciba una solicitud GET de X Challenge Response Check (CRC) y responda con una respuesta JSON correctamente formateada.
-
Registra la URL de tu webhook. Realizarás una solicitud POST al endpoint /webhooks.json?url=. Cuando realices esta solicitud, X enviará una solicitud CRC a tu aplicación web. Cuando un webhook se registra correctamente, la respuesta incluirá un webhook id. Este webhook id es necesario más adelante al realizar algunas solicitudes a la Account Activity API.
-
X enviará eventos de webhook de cuenta a la URL que registraste. Asegúrate de que tu aplicación web acepte solicitudes POST para los eventos entrantes. Estos eventos estarán codificados en JSON. Consulta aquí para ver ejemplos de payloads JSON de webhooks.
-
Una vez que tu aplicación web esté lista, el siguiente paso es agregar cuentas para las que recibir actividades. Al agregar (o eliminar) cuentas, realizarás solicitudes POST que hagan referencia al id de la cuenta. Consulta nuestra guía sobre cómo agregar suscripciones para obtener más información.
4. Validar la configuración
- Para validar que tu app y webhook están configurados correctamente, marca como favorito una Publicación de una de las cuentas de X a las que está suscrita tu app. Deberías recibir un
favorite_events mediante una solicitud POST a la URL de tu webhook por cada Favorito que reciban tus suscriptores.
- Ten en cuenta que pueden transcurrir hasta 10 segundos antes de que los eventos comiencen a entregarse después de agregar una suscripción.
Notas importantes
-
Al registrar la URL de tu webhook, tu aplicación web debe autenticarse con su token y secreto de consumidor y el token y secreto de acceso de usuario del propietario de la app.
-
Todos los Mensajes Directos entrantes se entregarán mediante webhooks. Todos los Mensajes Directos enviados a través de POST direct_messages/events/new (message_create) también se entregarán mediante webhooks. Esto es para que tu aplicación web pueda conocer los Mensajes Directos enviados a través de un cliente diferente.
-
Ten en cuenta que cada evento de webhook incluye un ID de usuario for_user_id que indica para qué suscripción se entregó el evento.
-
Si tienes a dos usuarios usando tu aplicación web para Mensajes Directos en la misma conversación, tu webhook recibirá dos eventos duplicados (uno por cada usuario). Tu aplicación web debe tener esto en cuenta.
-
Si tienes más de una aplicación web que comparte la misma URL de webhook y el mismo usuario asignado a cada app, el mismo evento se enviará a tu webhook múltiples veces (una por cada aplicación web).
-
En algunos casos, tu webhook puede recibir eventos duplicados. Tu aplicación de webhook debe ser tolerante a esto y eliminar duplicados usando el ID del evento.
-
No esperes que la respuesta de Quick Reply siga directamente a una solicitud. Un usuario puede ignorar una solicitud de Quick Reply y responder mediante un Mensaje Directo tradicional. El usuario también puede proporcionar una respuesta de Quick Reply a una solicitud a la que no haya respondido anteriormente en el hilo de mensajes.
-
Consulta el código de ejemplo:
-
Enterprise Account Activity API dashboard, una aplicación web de Node que muestra eventos de webhook usando el nivel empresarial de la Account Activity API e incluye funcionalidad de Replay.
-
El chatbot SnowBot, una aplicación web en Ruby creada sobre las Account Activity y Direct Message APIs. Esta base de código incluye un script para ayudar a configurar los webhooks de la Account Activity API.
Las APIs basadas en webhooks de X ofrecen dos métodos para confirmar la seguridad de tu servidor de webhooks:
- Las comprobaciones de desafío-respuesta permiten a X confirmar la propiedad de la aplicación web que recibe los eventos de webhook.
- El encabezado de firma en cada solicitud POST te permite confirmar que X es el origen de los webhooks entrantes.
Comprobaciones de desafío-respuesta
crc_token. Cuando se reciba esa solicitud, tu aplicación web deberá generar un response_token cifrado basado en el parámetro crc_token y en el Consumer Secret de tu App (detalles a continuación). El response_token debe estar codificado en JSON (consulta el ejemplo a continuación) y devolverse en un plazo de tres segundos. Cuando la operación se completa correctamente, se devolverá un id de webhook.
Se enviará un CRC cuando registres tu URL de webhook, por lo que implementar tu código de respuesta de CRC es un primer paso fundamental. Una vez que tu webhook esté establecido, X activará un CRC aproximadamente cada 24 horas desde la última vez que recibimos una respuesta correcta. Tu App también puede activar un CRC cuando sea necesario realizando una solicitud PUT con el id de tu webhook. Activar un CRC es útil mientras desarrollas tu aplicación de webhook, después de implementar nuevo código y reiniciar tu servicio.
Debes esperar que el crc_token cambie en cada solicitud CRC entrante y debes utilizarlo como mensaje en el cálculo, donde tu Consumer Secret es la clave.
En caso de que la respuesta no se envíe en un plazo de 3 segundos o deje de ser válida, se dejarán de enviar eventos al webhook registrado.
La solicitud de CRC se producirá:
- Cuando se registre una URL de webhook.
- Aproximadamente cada hora para validar tu URL de webhook.
- Puedes activar manualmente un CRC haciendo una solicitud PUT. A medida que desarrolles tu cliente de webhook, deberías planear activar manualmente el CRC mientras desarrollas tu respuesta al CRC.
Requisitos de la respuesta:
- Un hash HMAC SHA-256 codificado en Base64 creado a partir del
crc_token y el Consumer Secret de tu aplicación.
response_token válido y en formato JSON.- Latencia menor a 3 segundos.
- Código de respuesta HTTP 200.
Bibliotecas HMAC específicas del lenguaje:
Ejemplo de generación de token de respuesta en Python:
import base64
import hashlib
import hmac
import json
\# Define una ruta para la solicitud GET
@app.route('/webhooks/twitter', methods=\['GET'\])
def webhook_challenge():
# crea un hash HMAC SHA-256 a partir del token entrante y tu clave secreta de consumidor
sha256\_hash\_digest = hmac.new(TWITTER\_CONSUMER\_SECRET, msg=request.args.get('crc_token'), digestmod=hashlib.sha256).digest()
# construye los datos de respuesta con el hash codificado en base64
response = {
'response\_token': 'sha256=' + base64.b64encode(sha256\_hash_digest)
}
# devuelve una respuesta JSON con el formato adecuado
return json.dumps(response)
Ejemplo de respuesta JSON:
{
"response_token": "sha256=x0mYd8hz2goCTfcNAaMqENy2BFgJJfJOb4PdvTffpwg="
}
- AQUÍ hay un ejemplo de método de respuesta CRC escrito en Node.js.
- AQUÍ hay un ejemplo de método de respuesta CRC escrito en Ruby (consulta generate_crc_response y la ruta /GET que recibe eventos CRC).
Cuando recibes una solicitud POST de X, envías una solicitud GET para crear un webhook o envías una solicitud GET para realizar un CRC manual, se incluirá una firma hash en los encabezados como x-twitter-webhooks-signature. Esta firma se puede usar para validar que el origen de los datos es X. La firma hash de la solicitud POST comienza con sha256=, lo que indica el uso de HMAC SHA-256 para cifrar tu X App Consumer Secret y el payload. El hash de la solicitud GET se calcula a partir de la cadena de parámetros de consulta crc_token=token&nonce=nonce.
Pasos para validar una solicitud
- Genera un hash usando tu consumer secret y el cuerpo del payload entrante.
- Compara el hash generado con el valor x-twitter-webhooks-signature codificado en base64. Usa un método como compare_digest para reducir la vulnerabilidad a ataques de temporización.
Directrices de seguridad adicionales
Bloques de red agregados de X
-
199.59.148.0/22
-
199.16.156.0/22
-
192.133.77.0/26
-
64.63.15.0/24
-
64.63.31.0/24
-
64.63.47.0/24
-
202.160.128.0/24
-
202.160.129.0/24
-
202.160.130.0/24
Configuraciones de servidor recomendadas
- Obtener una calificación “A” en la prueba de ssllabs.com
- Habilitar TLS 1.2
- Habilitar Forward Secrecy
- Desactivar SSLv2
- Desactivar SSLv3 (debido a POODLE)
- Desactivar TLS 1.0
- Desactivar TLS 1.1
- Desactivar la compresión TLS
- Desactivar Session Tickets a menos que se roten las claves de Session Tickets.
- Establecer la opción “ssl_prefer_server_ciphers” o “SSLHonorCipherOrder” en la configuración SSL como “on”.
- Asegurarse de que la lista de cifrados sea moderna, por ejemplo:
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:DES-CBC3-SHA
Administrar webhooks y suscripciones
Creación y actualización de webhooks
Endpoints de administración de la configuración de webhooks:
| |
|---|
| Método | Enterprise |
| Registra una URL de webhook / Genera un webhook_id | POST webhooks |
| Devuelve todas las URL de webhook y sus estados | GET webhooks |
| Elimina la configuración de webhook actual de la aplicación | DELETE webhooks/:webhook_id |
| Activa manualmente una solicitud CRC | PUT webhooks/:webhook_id |
¿Por qué no puedo simplemente actualizar la URL del webhook?
Añadir y eliminar suscripciones de usuario
Endpoints para la gestión de suscripciones
| |
|---|
| Método | Enterprise |
| Añadir nueva suscripción de usuario | POST webhooks/:webhook_id/subscriptions/all |
| Obtener una suscripción de usuario | GET webhooks/:webhook_id/subscriptions/all |
| Devuelve una lista de todas las suscripciones activas | GET webhooks/:webhook_id/subscriptions/all/list |
| Desactiva una suscripción de usuario mediante OAuth solo de aplicación | DELETE webhooks/:webhook_id/subscriptions/:user_id/all.json |
Ten en cuenta lo siguiente: X debe habilitar el acceso a la Account Activity API para tu App de desarrollador antes de que puedas empezar a usar la API. Para ello, asegúrate de compartir el ID de la App que tienes previsto usar para la autenticación con tu gestor de cuenta o con tu equipo de soporte técnico.
| | | |
|---|
| Descripción | **Endpoint ** | OAuth 1.0a
(contexto de usuario) | OAuth 2.0 Bearer Token (solo aplicación) |
| Registrar una nueva URL de webhook para el contexto de aplicación dado | POST account_activity/webhooks | ✓ | |
| Devolver todas las URLs y sus estados para la aplicación dada | GET account_activity/webhooks | | ✓ |
| Ejecutar una comprobación de respuesta de desafío (CRC) para la URL de un webhook dado | PUT account_activity/webhooks/:webhook_id | ✓ | |
| Suscribir la aplicación a los eventos de cuenta de un usuario | POST account_activity/webhooks/:webhook_id/subscriptions/all | ✓ * | |
| Devolver un recuento de suscripciones actualmente activas | GET account_activity/subscriptions/count | | ✓ |
| Comprobar si una configuración de webhook está suscrita a los eventos de un usuario | GET account_activity/webhooks/:webhook_id/subscriptions/all | ✓ * | |
| Devolver una lista de suscripciones actualmente activas | GET account_activity/webhooks/:webhook_id/subscriptions/all/list | | ✓ |
| Eliminar un webhook | DELETE account_activity/webhooks/:webhook_id | ✓ | |
| [OBSOLETO] Desactivar una suscripción para el contexto de usuario y la aplicación proporcionados | DELETE account_activity/webhooks/:webhook_id/subscriptions/all | ✓ * | |
| Desactivar una suscripción usando OAuth de solo aplicación | DELETE /account_activity/webhooks/:webhook_id/subscriptions/:user_id/all.json | | ✓ |
| Reentregar actividades a un webhook | POST /1.1/account_activity/replay/webhooks/:webhook_id/subscriptions/all.json | | ✓ |
- Consumer Keys (API Key y Secret)
- Access Tokens (Access Token y Secret)
En el caso de los siguientes tres endpoints, se realizan acciones de escritura dentro del contexto de tu aplicación (no intervienen usuarios de X). Por lo tanto, los Access Tokens que debes proporcionar son los que pertenecen a tu App de desarrollador. Estos se pueden generar directamente desde la Consola de desarrollador, en la pestaña “Keys and tokens” de tu App.
Por otro lado, en el caso de los siguientes tres endpoints, estás realizando una solicitud que permite que tu aplicación acceda a datos protegidos en nombre de un usuario de X (por ejemplo, Mensajes Directos). Por lo tanto, debes proporcionar los Access Tokens que pertenecen al usuario suscriptor en cuestión. Los Access Tokens requeridos se pueden obtener usando el flujo OAuth de 3 partes (consulta OAuth 1.0a: how to obtain a user’s Access Tokens). Estos endpoints se han marcado con un asterisco en la tabla anterior (*).
Please note: Asegúrate de que tu App de desarrollador esté habilitada para “Read, Write, and Direct Messages.” Puedes cambiar esta configuración en la sección Projects & Apps de tu cuenta de desarrollador, en “App permissions” para la App de desarrollador seleccionada. Deberás volver a generar las credenciales de tu App después de cambiar la configuración de permisos. Please note: X debe habilitar el acceso a la Account Activity API para tu App de desarrollador antes de que puedas empezar a usar la API. Para ello, asegúrate de compartir el App ID que piensas usar para fines de autenticación con tu account manager o con el equipo de soporte técnico.
| | | |
|---|
| Descripción | **Endpoint ** | OAuth 1.0a
(contexto de usuario) | OAuth 2.0 Bearer Token (solo de aplicación) |
| Registrar una nueva URL de webhook para el contexto de aplicación especificado | POST account_activity/webhooks | ✓ | |
| Devolver todas las URL y sus estados para la aplicación especificada | GET account_activity/webhooks | | ✓ |
| Iniciar una comprobación de respuesta de desafío (CRC) para la URL de un webhook determinado | PUT account_activity/webhooks/:webhook_id | ✓ | |
| Suscribir la aplicación a los eventos de cuenta de un usuario | POST account_activity/webhooks/:webhook_id/subscriptions/all | ✓ * | |
| Devolver el número de suscripciones activas actualmente | GET account_activity/subscriptions/count | | ✓ |
| Comprobar si una configuración de webhook está suscrita a los eventos de un usuario | GET account_activity/webhooks/:webhook_id/subscriptions/all | ✓ * | |
| Devolver una lista de suscripciones activas actualmente | GET account_activity/webhooks/:webhook_id/subscriptions/all/list | | ✓ |
| Eliminar un webhook | DELETE account_activity/webhooks/:webhook_id | ✓ | |
| [OBSOLETO] Desactivar una suscripción para el contexto de usuario y la aplicación proporcionados | DELETE account_activity/webhooks/:webhook_id/subscriptions/all | ✓ * | |
| Desactivar una suscripción usando OAuth de solo aplicación | DELETE /account_activity/webhooks/:webhook_id/subscriptions/:user_id/all.json | | ✓ |
| Volver a enviar actividades a un webhook | POST /1.1/account_activity/replay/webhooks/:webhook_id/subscriptions/all.json | | ✓ |
- Consumer Keys (API Key y Secret)
- Access Tokens (Access Token y Secret)
En el caso de los tres endpoints siguientes, realizas acciones de escritura dentro del contexto de tu aplicación (no se involucran usuarios de X). Por lo tanto, los Access Tokens que debes proporcionar son los que pertenecen a tu App de desarrollador. Estos se pueden generar directamente desde la Consola de desarrollador, en la pestaña “Keys and tokens” de tu App.
Por otro lado, en el caso de los siguientes tres endpoints, estás realizando una solicitud que permite que tu aplicación acceda a datos protegidos en nombre de un usuario de X (por ejemplo, Mensajes Directos). Por lo tanto, debes proporcionar los Access Tokens que pertenecen al usuario suscriptor en cuestión. Los Access Tokens requeridos se pueden obtener utilizando el flujo OAuth de 3 patas (consulta OAuth 1.0a: cómo obtener los Access Tokens de un usuario). Estos endpoints se han marcado con un asterisco en la tabla anterior (*).
Ten en cuenta: Asegúrate de que tu App de desarrollador esté habilitada para “Read, Write, and Direct Messages.” Puedes cambiar esta configuración en la sección Projects & Apps de tu cuenta de desarrollador, en “App permissions” para la App de desarrollador seleccionada. Deberás volver a generar las credenciales de tu App después de cambiar la configuración de permisos. Enterprise
Uno de los beneficios del nivel Enterprise de la Account Activity API es un mecanismo de reintento para eventos de webhook. Si no se recibe un código de respuesta HTTP 200 de “success”, el servidor de X iniciará un mecanismo de reintento y reenviará el evento de webhook hasta tres veces durante un período de cinco minutos. Este servicio de reintento de eventos de webhook ayuda a proporcionar fiabilidad y recuperación de eventos cuando se producen problemas de red y durante interrupciones y despliegues del servicio en el lado del cliente.
La API Account Activity proporciona una función de reintento cuando la aplicación web del cliente no devuelve una respuesta 200 de “success” para un evento de webhook de actividad de cuenta. Cuando el lado del cliente no confirma la recepción correcta de un evento, X asume que el evento no se recibió. Si se recibe una respuesta distinta de 200, no se recibe una respuesta en un plazo de tres segundos o no recibimos ninguna respuesta en absoluto, volvemos a intentar la solicitud y la mantenemos abierta durante tres segundos. Esto significa que tienes aproximadamente cinco segundos, repartidos en dos intentos, para responder y recibir la actividad que estamos intentando enviar a tu URL de webhook. En el caso de que tu servidor no responda o devuelva un error transitorio, volveremos a intentarlo durante cinco minutos. Habrá un total de tres intentos de reintento para confirmar la validación. Esto proporciona redundancia y sirve como garantía de que recibes todos los eventos de webhook. Ten en cuenta que las suscripciones con reintentos recibirán eventos reintentados para cualquiera/todas las actividades de todos los usuarios suscritos en su webhook.
Si no confirmas la validación dentro de estos ocho intentos, la actividad ya no estará disponible a través de la API Account Activity.
La Account Activity API intentará reenviar hasta tres veces durante un período de cinco minutos, hasta que se reciba una respuesta 200. Consulta la siguiente tabla para obtener más detalles. Transcurridos aproximadamente cinco minutos, la actividad ya no se puede volver a enviar a través de la Account Activity API. Deberás usar otros endpoints de X para recopilar los datos que falten. Por ejemplo, las APIs de búsqueda pueden utilizarse para recuperar Publicaciones relevantes, Retweets, Tweets citados, menciones y respuestas. Los Mensajes Directos que se hayan perdido pueden recuperarse con este endpoint.
|
|---|
| Actividad creada, se realiza un POST a la URL del webhook desde la API de Account Activity y el tiempo de espera se agota en tres segundos. |
| Espera tres segundos después de que finalice el tiempo de espera anterior, luego realiza un POST a la URL del webhook desde la API de Account Activity y el tiempo de espera se agota en tres segundos. |
| Espera 27 segundos después de que finalice el tiempo de espera anterior, luego realiza un POST a la URL del webhook desde la API de Account Activity y el tiempo de espera se agota en tres segundos. |
| Espera 242 segundos después de que finalice el tiempo de espera anterior, luego realiza un POST a la URL del webhook desde la API de Account Activity y el tiempo de espera se agota en tres segundos. |
| La API de Account Activity dejará de intentar realizar solicitudes POST después de esto. El Client debe usar otros endpoints de X para recuperar los datos. |
Estructura del objeto de datos de Account Activity
| Object | Details |
|---|
| for_user_id | Identifica la suscripción de usuario a la que está asociado el evento. |
| is_blocked_by | (condicional) Se muestra solo cuando otro usuario menciona a tu usuario suscrito. Se incluye si es true únicamente para eventos de mención de Publicaciones. |
| source | El usuario que está realizando la actividad. Por ejemplo, el usuario que sigue, bloquea o silencia es el usuario de origen. |
| target | El usuario al que se aplica la actividad. Por ejemplo, el usuario que está siendo seguido, bloqueado o silenciado es el usuario de destino. |
| Message Type | Details |
|---|
| tweet_create_events | Carga útil del estado de la Publicación cuando se realiza cualquiera de las siguientes acciones por o hacia el usuario de la suscripción: Publicaciones, Retweets, respuestas, @menciones, QuoteTweets, Retweet de Quote Tweets. |
| favorite_events | Evento de favorito (Me gusta) con el usuario y el destino. |
| follow_events | Evento de seguir con el usuario y el destino. |
| unfollow_events | Evento de dejar de seguir con el usuario y el destino. |
| block_events | Evento de bloqueo con el usuario y el destino. |
| unblock_events | Evento de desbloqueo con el usuario y el destino. |
| mute_events | Evento de silenciamiento con el usuario y el destino. |
| unmute_events | Evento de dejar de silenciar con el usuario y el destino. |
| user_event | Eventos de revocación enviados cuando un usuario elimina la autorización de la aplicación y la suscripción se elimina automáticamente. |
| direct_message_events | Estado de mensaje directo con el usuario y el destino cuando se envía o se recibe un mensaje directo. |
| direct_message_indicate_typing_events | Evento de escritura de mensaje directo con el usuario y el destino. |
| direct_message_mark_read_events | Evento de lectura de mensaje directo con el usuario y el destino. |
| tweet_delete_events | Aviso de Publicaciones eliminadas para facilitar el mantenimiento del cumplimiento normativo. |
{
"for_user_id": "2244994945",
"tweet_create_events": [
{
<Tweet Object>
}
]
}
{
"for_user_id": "2244994945",
"user_has_blocked": "false",
"tweet_create_events": [
{
<Tweet Object>
}
]
}
{
"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>
}
}]
}
{
"for_user_id": "2244994945",
"follow_events": [{
"type": "follow",
"created_timestamp": "1517588749178",
"target": {
<User Object >
},
"source": {
< User Object >
}
]
}
}
{
"for_user_id": "2244994945",
"follow_events": [{
"type": "unfollow",
"created_timestamp": "1517588749178",
"target": {
<User Object >
},
"source": {
< User Object >
}
]
}
}
{
"for_user_id": "2244994945",
"block_events": [{
"type": "block",
"created_timestamp": "1518127020304",
"source": {
<User Object>
},
"target": {
<User Object>
}
}]
}
{
"for_user_id": "2244994945",
"block_events": [{
"type": "unblock",
"created_timestamp": "1518127020304",
"source": {
<User Object>
},
"target": {
<User Object>
}
}]
}
{
"for_user_id": "2244994945",
"mute_events": [
{
"type": "mute",
"created_timestamp": "1518127020304",
"source": {
<User Object>
},
"target": {
<User Object>
}
}
]
}
{
"for_user_id": "2244994945",
"mute_events": [
{
"type": "unmute",
"created_timestamp": "1518127020304",
"source": {
<User Object>
},
"target": {
<User Object>
}
}
]
}
{
"user_event": {
"revoke": {
"date_time": "2018-05-24T09:48:12+00:00",
"target": {
"app_id": "13090192"
},
"source": {
"user_id": "63046977"
}
}
}
}
{
"for_user_id": "4337869213",
"direct_message_events": [{
"type": "message_create",
"id": "954491830116155396",
"created_timestamp": "1516403560557",
"message_create": {
"target": {
"recipient_id": "4337869213"
},
"sender_id": "3001969357",
"source_app_id": "13090192",
"message_data": {
"text": "Hello World!",
"entities": {
"hashtags": [],
"symbols": [],
"user_mentions": [],
"urls": []
}
}
}
}],
"apps": {
"13090192": {
"id": "13090192",
"name": "FuriousCamperTestApp1",
"url": "https://x.com/furiouscamper"
},
"users": {},
"3001969357": {
"id": "3001969357",
"created_timestamp": "1422556069340",
"name": "Jordan Brinks",
"screen_name": "furiouscamper",
"location": "Boulder, CO",
"description": "Alter Ego - X PE opinions-are-my-own",
"url": "https://t.co/SnxaA15ZuY",
"protected": false,
"verified": false,
"followers_count": 22,
"friends_count": 45,
"statuses_count": 494,
"profile_image_url": "null",
"profile_image_url_https": "https://pbs.twimg.com/profile_images/851526626785480705/cW4WTi7C_normal.jpg"
},
"4337869213": {
"id": "4337869213",
"created_timestamp": "1448312972328",
"name": "Harrison Test",
"screen_name": "Harris_0ff",
"location": "Burlington, MA",
"protected": false,
"verified": false,
"followers_count": 8,
"friends_count": 8,
"profile_image_url": "null",
"statuses_count": 240,
"profile_image_url_https": "https://abs.twimg.com/sticky/default_profile_images/default_profile_normal.png"
}
}
}
direct_message_indicate_typing_events
{
"for_user_id": "4337869213",
"direct_message_indicate_typing_events": [{
"created_timestamp": "1518127183443",
"sender_id": "3284025577",
"target": {
"recipient_id": "3001969357"
}
}],
"users": {
"3001969357": {
"id": "3001969357",
"created_timestamp": "1422556069340",
"name": "Jordan Brinks",
"screen_name": "furiouscamper",
"location": "Boulder, CO",
"description": "Alter Ego - X PE las-opiniones-son-mías",
"url": "https://t.co/SnxaA15ZuY",
"protected": false,
"verified": false,
"followers_count": 23,
"friends_count": 47,
"statuses_count": 509,
"profile_image_url": "null",
"profile_image_url_https": "https://pbs.twimg.com/profile_images/851526626785480705/cW4WTi7C_normal.jpg"
},
"3284025577": {
"id": "3284025577",
"created_timestamp": "1437281176085",
"name": "Bogus Bogart",
"screen_name": "bogusbogart",
"protected": true,
"verified": false,
"followers_count": 1,
"friends_count": 4,
"statuses_count": 35,
"profile_image_url": "null",
"profile_image_url_https": "https://pbs.twimg.com/profile_images/763383202857779200/ndvZ96mE_normal.jpg"
}
}
}
direct_message_mark_read_events
{
"for_user_id": "4337869213",
"direct_message_mark_read_events": [{
"created_timestamp": "1518452444662",
"sender_id": "199566737",
"target": {
"recipient_id": "3001969357"
},
"last_read_event_id": "963085315333238788"
}],
"users": {
"199566737": {
"id": "199566737",
"created_timestamp": "1286429788000",
"name": "Le Braat",
"screen_name": "LeBraat",
"location": "Denver, CO",
"description": "data by day @X, design by dusk",
"protected": false,
"verified": false,
"followers_count": 299,
"friends_count": 336,
"statuses_count": 752,
"profile_image_url": "null",
"profile_image_url_https": "https://pbs.twimg.com/profile_images/936652894371119105/YHEozVAg_normal.jpg"
},
"3001969357": {
"id": "3001969357",
"created_timestamp": "1422556069340",
"name": "Jordan Brinks",
"screen_name": "furiouscamper",
"location": "Boulder, CO",
"description": "Alter Ego - X PE opinions-are-my-own",
"url": "https://t.co/SnxaA15ZuY",
"protected": false,
"verified": false,
"followers_count": 23,
"friends_count": 48,
"statuses_count": 510,
"profile_image_url": "null",
"profile_image_url_https": "https://pbs.twimg.com/profile_images/851526626785480705/cW4WTi7C_normal.jpg"
}
}
}
{
"for_user_id": "930524282358325248",
"tweet_delete_events": [
{
"status": {
"id": "1045405559317569537",
"user_id": "930524282358325248"
},
"timestamp_ms": "1432228155593"
}
]
}
API de Reproducción de Actividad de Cuenta
Enterprise
La API de Reproducción de Actividad de Cuenta es una herramienta de recuperación de datos que te permite recuperar eventos de hasta cinco días atrás. Debe utilizarse para recuperar datos en escenarios en los que tu servidor de webhook deja de recibir eventos, ya sea debido a desconexiones que duren más que la ventana de reintentos, o en aquellos escenarios de recuperación ante desastres en los que necesitas unos días para restaurar tu sistema a la normalidad.
La API de Reproducción de Actividad de Cuenta se desarrolló para cualquier escenario en el que no puedas ingestar actividades durante un período de tiempo. Entrega actividades al mismo webhook utilizado para la entrega original en tiempo real de las actividades. Este producto es una herramienta de recuperación y no una herramienta de carga histórica (backfill), lo que significa que los eventos solo se reproducirán si se intentó una entrega previa de los mismos. La API de Reproducción de Actividad de Cuenta no puede entregar eventos correspondientes a un período anterior al momento de creación de una suscripción.
Uso de Account Activity Replay API
Disponibilidad de datos y tipos
Introducción a la migración
- User Streams
- Site Streams
- GET direct_messages
- GET direct_messages/sent
- GET direct_messages/show
- POST direct_messages/new
- POST direct_messages/destroy
Contamos con nuevos endpoints y servicios que proporcionan un acceso similar y, en el caso de los Mensajes Directos, funcionalidad adicional:
Para ayudarte a realizar una migración fluida a estos nuevos endpoints y servicios, disponemos de dos guías de migración:
Además, contamos con una serie de vídeos sobre Account Activity API y cómo empezar.
Y, por último, tenemos ejemplos de código para ampliar tu comprensión y ayudarte a comenzar rápidamente:
- El Account Activity Dashboard es una aplicación web de Node.js de ejemplo con scripts auxiliares para comenzar a usar Account Activity API.
- SnowBot es un chatbot de ejemplo que usa Account Activity API y endpoints REST de Mensajes Directos. Está escrito en Ruby, utiliza el framework web Sinatra y se despliega en Heroku.
Guía de migración: migrar de User Streams/Site Streams a Account Activity API
Diferencias y consideraciones de migración
Gestión de suscripciones de usuario
Sigue los pasos a continuación para migrar fácilmente de la Site Streams API a la Account Activity API
- Número de webhooks necesarios
- Suscripciones/usuarios autorizados actuales/proyectados gestionados en tu aplicación
- Número actual de aplicaciones cliente de X
- El nivel de soporte que prefieres por parte de X (soporte mediante foro o soporte enterprise gestionado 1:1)
- El precio de cada paquete
Paso 2: Verifica la configuración de tu app de X en la Consola de desarrollador
La app de X que se utiliza actualmente para User Streams o Site Streams aparecerá en la lista para el usuario propietario dentro de la Consola de desarrollador. Esta app de X también puede usarse para Account Activity API para conservar los usuarios autorizados de esa aplicación. También se puede crear una nueva app y los usuarios pueden volver a autorizar esta nueva app si se desea. Si estás creando una nueva app en nombre de una empresa, se recomienda que crees la app con una cuenta corporativa de X @handle.
- Habilita “Read, Write and Access direct messages” en la pestaña de permissions de la página de tu app de X.
*Ten en cuenta que cambiar estas opciones no es retroactivo; cualquier usuario autorizado conservará la configuración de autorización del momento en que fue autorizado. Si un usuario aún no te ha otorgado acceso de lectura, escritura y mensajes directos, deberás hacer que ese usuario vuelva a autorizar tu aplicación.
- Si no estás familiarizado con X Sign-in y cómo funcionan los contextos de usuario con la X API, revisa Obtaining Access Tokens.
- Genera tokens de acceso para el propietario de la app de X en la parte inferior de la pestaña “Keys and Tokens”. En esta misma pestaña, toma nota de tu Consumer Key, Consumer Secret, Access Token y Access Token Secret. Los necesitarás para usar la API.
- Genera un Bearer Token usando tu Consumer Key y Consumer Secret para métodos de la API en modo application-only.
Paso 3: Configura tus webhooks
-
Crea una aplicación web con un endpoint para usar como tu webhook y recibir eventos (por ejemplo, https://your_domain.com/webhook/twitter o https://webhooks.your_domain.com).
-
Usa tu Consumer Key, Consumer Secret, Access Token y Access Token Secret al crear tu webhook. Ten en cuenta que tu endpoint debe devolver una respuesta JSON con un
response_token que sea un hash HMAC SHA-256 codificado en base64 creado a partir del crc_token y el Consumer Secret de tu app.
-
Revisa la documentación de Securing Webhooks, prestando especial atención a los requisitos de Challenge Response Check (CRC).
-
Asegúrate de que tu webhook admita solicitudes POST para eventos entrantes y solicitudes GET para el CRC.
-
Asegúrate de que tu webhook tenga baja latencia (<3 segundos para responder a solicitudes POST)
Paso 4: Valida la configuración de tu webhook
- Las Webhook APIs protegerán tus webhooks de dos maneras:
- Requerir comprobaciones de desafío-respuesta para validar que el propietario del webhook es el propietario de la aplicación web.
- Un encabezado de firma en cada solicitud POST para que tu aplicación web valide el origen.
- Para verificar que eres tanto el propietario de la aplicación web como de la URL del webhook, X realizará un Challenge Response Check (CRC), que no debe confundirse con una comprobación de redundancia cíclica.
- Se enviará una solicitud GET con un parámetro llamado
crc_token a la URL de tu webhook. Tu endpoint debe devolver una respuesta JSON con un response_token que sea un hash HMAC SHA-256 codificado en base64 creado a partir del crc_token y el Consumer Secret de tu app.
- Se debe esperar que el
crc_token cambie en cada solicitud de CRC entrante. El crc_token debe usarse como mensaje en el cálculo, donde tu Consumer Secret es la clave.
- En caso de que la respuesta sea inválida, se dejarán de enviar eventos al webhook registrado.
Paso 5: Crea suscripciones para cada usuario autorizado de User Streams o Site Streams
Conversión desde User Streams a la Account Activity API:
- Genera una lista de tus suscripciones de usuario actuales en User Streams
- Configura tus nuevas suscripciones de Account Activity API mediante la solicitud: POST account_activity/all/:env_name/subscriptions
- Confirma tus suscripciones de Account Activity API mediante la solicitud: _GET account_activity/all/:env_name/subscriptions/list
_
Conversión a Account Activity API desde Site Streams (usando control streams):
- Genera una lista de tus suscripciones actuales en Site Streams mediante la solicitud: GET /1.1/site/c/:stream_id/info.json
- Configura tus nuevas suscripciones de Account Activity API mediante la solicitud: POST account_activity/all/:env_name/subscriptions
- Confirma tus suscripciones de Account Activity API mediante la solicitud: _GET account_activity/all/:env_name/subscriptions/list
_
Registro de un webhook y creación de suscripciones (sin migrar desde Site Streams o User Streams)
El panel de Account Activity (aplicación de ejemplo de Account Activity API)
- Descarga la aplicación de ejemplo Account Activity Dashboard aquí (usa Node.js)
- Sigue las instrucciones del README para instalar e iniciar la aplicación
- Una vez que la aplicación se haya iniciado, puedes usar la interfaz de usuario para configurar fácilmente tu webhook y crear una nueva suscripción
| Tipo de mensaje | Detalles |
|---|
| tweet_create_events | Carga útil del estado de la Publicación cuando se realiza cualquiera de las siguientes acciones por parte del usuario de la suscripción o dirigidas a él: Publicaciones, Retweets, respuestas, menciones @, Tweets citados |
| favorite_events | Evento de favorito (like) con el usuario y el objetivo. |
| follow_events | Evento de seguir con el usuario y el objetivo. |
| block_events | Evento de bloqueo con el usuario y el objetivo. |
| mute_events | Evento de silenciar con el usuario y el objetivo. |
| direct_message_events | Evento de mensaje directo con el usuario y el objetivo. |
| direct_message_indicate_typing_events | Evento de escritura en mensaje directo con el usuario y el objetivo. |
| direct_message_mark_read_events | Evento de lectura de mensaje directo con el usuario y el objetivo. |
Tipos de mensajes de streaming en desuso
| |
|---|
| Blank lines | Las líneas en blanco ya no se entregarán en Account Activity API, ya que se utilizaban como mensajes de mantenimiento de la conexión en User Streams y Site Streams. |
| Limit notices | Los avisos de límite ya no se enviarán al webhook correspondiente. En su lugar, los usuarios pueden llamar a la API para obtener el uso actual de los identificadores disponibles. Esto se incluirá en la Consola de desarrollador en algún momento en el futuro. |
| Disconnect messages | Los avisos de desconexión ya no serán necesarios, ya que los webhooks no dependen de una conexión activa. |
| Stall warnings | Las advertencias de bloqueo ya no serán necesarias, ya que los webhooks no dependen de una conexión activa capaz de manejar grandes cantidades de mensajes entrantes. |
| Friends list | Las listas de amigos ya no se enviarán de forma proactiva. Ahora habrá un endpoint REST para obtener esta información. |
Tipos de eventos obsoletos
| | | | |
|---|
| Descripción | Nombre del evento | Origen | Destino | Objeto de destino |
| El usuario elimina una publicación | delete | Usuario actual | Usuario actual | Publicación |
| Un usuario seguido elimina una publicación | delete | Usuario seguido | Usuario seguido | Publicación |
| El usuario quita de favoritos una publicación | unfavorite | Usuario actual | Autor de la publicación | Publicación |
| Se quita de favoritos la publicación de un usuario | unfavorite | Usuario que quita de favoritos | Usuario actual | Publicación |
| El usuario deja de seguir a alguien | unfollow | Usuario actual | Usuario seguido | Null |
| El usuario crea una lista | list_created | Usuario actual | Usuario actual | Lista |
| El usuario elimina una lista | list_destroyed | Usuario actual | Usuario actual | Lista |
| El usuario edita una lista | list_updated | Usuario actual | Usuario actual | Lista |
| El usuario agrega a alguien a una lista | list_member_added | Usuario actual | Usuario agregado | Lista |
| El usuario es agregado a una lista | list_member_added | Usuario que agrega | Usuario actual | Lista |
| El usuario quita a alguien de una lista | list_member_removed | Usuario actual | Usuario eliminado | Lista |
| El usuario es quitado de una lista | list_member_removed | Usuario que elimina | Usuario actual | Lista |
| El usuario se suscribe a una lista | list_user_subscribed | Usuario actual | Propietario de la lista | Lista |
| Se suscriben a la lista de un usuario | list_user_subscribed | Usuario que se suscribe | Usuario actual | Lista |
| El usuario cancela la suscripción a una lista | list_user_unsubscribed | Usuario actual | Propietario de la lista | Lista |
| Se cancela la suscripción a la lista de un usuario | list_user_unsubscribed | Usuario que cancela la suscripción | Usuario actual | Lista |
| El usuario actualiza su perfil | user_update | Usuario actual | Usuario actual | Null |
| El usuario actualiza el estado de protección de su cuenta | user_update | Usuario actual | Usuario actual | Null |
Guía de migración de Mensajes Directos
Nuevas funciones
Los nuevos endpoints de la API de Mensajes Directos incorporan varias funcionalidades nuevas y ofrecen un acceso mejorado a Mensajes Directos anteriores. Las nuevas funciones incluyen:
- Compatibilidad con archivos multimedia adjuntos (imagen, GIF y video).
- Posibilidad de solicitar a los usuarios respuestas estructuradas con una lista de opciones predefinida.
- Hasta 30 días de acceso a Mensajes Directos anteriores.
Para ver la lista completa de las nuevas funciones de Mensajes Directos y de los nuevos endpoints de la API, consulta la documentación técnica.
Diferencias y consideraciones de migración
Nuevo objeto de Mensaje Directo
{
"type": "message_create",
"id": "1234858592",
"created_timestamp": "1392078023603",
"initiated_via": {
"tweet_id": "123456",
"welcome_message_id": "456789"
},
"message_create": {
"target": {
"recipient_id": "1234858592"
},
"sender_id": "3805104374",
"source_app_id": "268278",
"message_data": {
"text": "Blue Bird",
"entities": {
"hashtags": [],
"symbols": [],
"urls": [],
"user_mentions": [],
},
"quick_reply_response": {
"type": "options",
"metadata": "external_id_2"
},
"attachment": {
"type": "media",
"media": {
...
}
}
}
}
- Estructura de objeto de Mensaje Directo completamente nueva.
- Objeto de usuario simplificado.
- Nueva información disponible (respuestas a respuestas rápidas, archivos adjuntos, etc.).
Envío de Mensajes Directos
twurl -A 'Content-type: application/json' -X POST /1.1/direct\_messages/events/new.json -d '{"event": {"type": "message\_create", "message\_create": {"target": {"recipient\_id": "4534871"}, "message_data": {"text": "Hello World!"}}}}'
- El mensaje se define en el cuerpo de la solicitud POST en formato JSON
- El encabezado Content-Type debe establecerse en application/json
- El cuerpo JSON no se incluye en la generación de la firma de OAuth
Recuperar Mensajes Directos
- Los mensajes enviados y recibidos ahora se devuelven en el mismo endpoint.
- Se devuelven mensajes de hasta 30 días de antigüedad.
- Paginación basada en cursores.
- Acceso en tiempo real a Mensajes Directos mediante webhook.
Eliminación de Mensajes Directos
- Para eliminar un mensaje directo se requiere el id.
- El nuevo endpoint requiere una solicitud DELETE.
- La forma en que los mensajes directos eliminados se reflejan en los clientes oficiales de X permanece sin cambios.
**¿Tienes preguntas sobre cómo migrar a los nuevos endpoints de mensajes directos?
**Publica tu pregunta en el foro de la comunidad de desarrolladores en devcommunity.com.
¿Cuáles son las ventajas de usar la Account Activity API?
La Account Activity API usa webhooks, lo que significa que, a diferencia de las APIs de streaming, no necesitas mantener una conexión abierta para que podamos enviarte información. Los webhooks también son diferentes de las APIs REST porque no tienes que hacernos cientos de solicitudes cada 15 minutos para obtener los datos que te interesan. Esto aumenta la eficiencia entre un usuario y tu app, ya que entrega los datos cuando ocurren.
La Account Activity API tiene varias ventajas:
- Velocidad: entregamos los datos a la velocidad de X.
- Simplicidad: entregamos todos los eventos de una cuenta a través de una única conexión de webhook. Las actividades entregadas en la API incluyen Publicaciones, @menciones, respuestas, Retweets, Quote Tweets, Retweets de Quote Tweets, favoritos, mensajes directos enviados, mensajes directos recibidos, follows, blocks y mutes.
- Escalabilidad: recibes todas las actividades de una cuenta que administras sin estar restringido por ningún límite de tasa ni topes de eventos.
La Account Activity API está disponible como una oferta de sandbox premium, premium de pago y enterprise, por lo que puedes escalar según necesites más cuentas para funciones de responsabilidad o funcionalidad adicional.
Para comenzar, descarga fragmentos de código de ejemplo desde GitHub.
¿Cómo identifico qué nivel de producto es mejor para mí?
Lee nuestra página de Account Activity API Overview para obtener más información sobre las diferencias entre las opciones Premium y la opción Enterprise.
¿Cuál es la diferencia entre un entorno Premium y un webhook Enterprise?
No hay ninguna diferencia. Cada entorno Premium tendrá su propio webhook_id.
Necesito entornos de desarrollo, staging y producción para Account Activity API, ¿es esto posible?
¡Sí! Con los niveles de pago de Account Activity API (Premium de pago y Enterprise), es posible registrar varias URL de webhook y administrar las suscripciones por separado para cada una mediante los métodos de la API. Además, se pueden agregar varias apps cliente a una allowlist para mantener la autorización de tus usuarios autorizados actuales.
¿Tienen alguna guía paso a paso sobre cómo configurar la Account Activity API?
De hecho, ¡sí tenemos!
-
Si recién estás comenzando, te recomendamos que visites nuestra guía Getting started with webhooks
-
Sigue nuestros scripts proporcionados por X Dev:
- Account Activity API dashboard, una aplicación web Node que muestra eventos de webhook.
- El chatbot SnowBot, una aplicación web Ruby creada sobre las Account Activity y Direct Message APIs. Este código base incluye un script para ayudar a configurar los webhooks de Account Activity API.
¿Hay alguna forma de recuperar datos si nuestro sistema deja de funcionar durante un período de tiempo?
Con los niveles de pago de Account Activity API (Premium de pago y Enterprise), nuestro sistema reintentará enviarte las actividades varias veces durante un período de cuatro horas. Si tu sistema no responde dentro de ese período de cuatro horas, la actividad se perderá y tendrás que usar otros endpoints REST para recuperar datos dentro de un plazo de 7 días.
Te sugerimos que uses tus distintos webhooks, o entornos, como herramienta de redundancia, como la Account Activity Replay API, para asegurarte de no perder ninguna actividad si uno de tus sistemas deja de funcionar.
¿Qué autenticación tengo que usar con la Account Activity API?
Los métodos de autorización requeridos para Account Activity API se describen por método en las páginas de referencia de la API. Si recién estás comenzando con la autenticación de X, te recomendamos que leas esta sección.
¿Qué es una comprobación de desafío-respuesta (CRC)?
La verificación de respuesta al desafío de la Account Activity API es una función de seguridad implementada para garantizar que las actividades de la Account Activity API se envíen al desarrollador adecuado. También puede ser utilizada por los desarrolladores para asegurarse de que los datos que están recibiendo provienen de X. X enviará automáticamente un CRC a tu URL de webhook una vez cada 24 horas, a partir de la última vez que se validó la URL del webhook. Tu sistema debe responder con una respuesta válida en un plazo de 3 segundos para seguir validado.
Visita la página Protección de webhooks para obtener más detalles.
¿Hay algo que invalidaría inmediatamente mi URL de webhook?
Si ocurre una de las siguientes situaciones, marcaremos inmediatamente tu webhook como inválido:
- El servidor responde a un CRC con un token incorrecto. En este caso, nuestro sistema no reintentará enviarte la actividad.
- La URL del webhook tiene configurado un certificado incorrecto. En este caso, nuestro sistema no reintentará enviarte la actividad.
- Tu servidor devuelve un código de respuesta que no es 2XX, 4XXX ni 5XXX.
- Especificas el uso de gzip sin enviarlo realmente.
- No especificas el uso de gzip, pero en realidad lo envías en la respuesta.
¿Recibiré actividades duplicadas si estoy suscrito a usuarios que interactúan entre sí?
Sí. Si tu aplicación web tiene suscripciones activas para el Usuario A y el Usuario B, y el Usuario A menciona al Usuario B en una Publicación, se enviarán dos actividades POST al webhook registrado. Cada actividad tendrá un indicador “for_user_id” para mostrar a qué suscripción pertenece la actividad.
**Cuando creo una suscripción a mi webhook, ¿puedo reemplazar la parte /all/ del siguiente endpoint con otros objetos de datos de Account Activity para limitar las actividades que entrega la API? **POST https://api.x.com/1.1/account_activity/all/:env_name/subscriptions.json
No, esto no es posible. En la situación actual, solo tenemos disponible el producto /all/.
**¿Hay alguna forma de usar la Account Activity API sin solicitar permisos de Mensajes Directos a los usuarios? **
En este momento, se requieren permisos de Mensajes Directos porque no existe ninguna forma de “filtrar” las actividades de Mensajes Directos para esta API.
¿Existe una versión sandbox de la Account Activity API?
Sí, ofrecemos una opción de sandbox para pruebas. Nuestra opción de sandbox está limitada a un único webhook con un máximo de 15 suscripciones. Puedes leer más sobre la opción de sandbox en nuestra documentación.
**¿Es posible usar la Account Activity API para obtener Retweets de Publicaciones que mencionan a usuarios suscritos? **
Lamentablemente, esto no forma parte de las actividades entregadas con esta API. Para esto, sugerimos usar la Streaming API.
¿Cuáles son los posibles tipos de actividad que están representados por un tweet_create_event?
Se enviará una carga útil de tweet_create_event:
Si el usuario suscrito realiza cualquiera de las siguientes acciones:
- Crea una Publicación
- Hace Retweet
- Responde a una Publicación
Si otro usuario:
- @menciona* al usuario suscrito
- Cita un Tweet creado por el usuario suscrito
*Nota: La Account Activity API solo entrega eventos cuando el usuario suscrito recibiría una notificación de X y podría ver el evento públicamente. Esto significa que, si la cuenta mencionada (@userA) sigue a la cuenta protegida (@userB), entonces UserA recibirá una notificación de que UserB lo mencionó. Si UserA no sigue a UserB (y no ha sido aprobado por UserB), UserA no recibirá una notificación, y por lo tanto no se enviaría un tweet_create_event a través de AAA si @userA tuviera una suscripción.
Si un usuario bloqueado menciona a mi usuario suscrito, ¿cómo puedo identificarlo?
Verás un campo booleano user_has_blocked en el nivel superior de la respuesta JSON, establecido en “true” o “false”. Este campo solo se expondrá en menciones en Publicaciones.
Enterprise
¿Cómo puedo añadir mi App a una allowlist o comprobar si mi App ya está en la allowlist?
Para gestionar las X apps que has añadido a una allowlist para el acceso mediante las Enterprise APIs, ponte en contacto con tu account manager y facilítale tu app ID. Puedes encontrar tu app ID yendo a la página “Apps” en la Consola de desarrollador.
Si tengo acceso a tres webhooks, ¿puedo usar tres webhooks para cada una de las apps que he registrado para uso empresarial?
El límite de webhooks se establece a nivel de cuenta, no a nivel de app. Si tienes acceso a tres webhooks y dos apps registradas para uso empresarial, puedes usar dos webhooks en una app y el tercero en la otra app, pero no tres en cada app.
¿Puedo especificar qué tipos de eventos se volverán a entregar usando la Account Activity Replay API?
Los tipos de eventos a reproducir no se pueden especificar. Se volverán a reproducir todos los eventos entregados durante el intervalo de fecha y hora especificado.
¿Habrá reintentos si mi aplicación no logra procesar un evento de la Account Activity Replay API?
No, no habrá reintentos. Si una aplicación no logra procesar un evento enviado por la Account Activity Replay API, se puede enviar otro Replay job para el mismo período de tiempo para intentar la reentrega de cualquier Replay event que se haya perdido.
¿Qué debo hacer cuando recibo un evento de finalización con éxito parcial (partial success)?
Sugerimos que tomes nota de las marcas de tiempo (timestamps) de los eventos que se recibieron y solicites otro Replay job para los eventos que faltaron.
¿Cuántos Replay jobs de Account Activity Replay API puedo tener en ejecución al mismo tiempo?
Solo puede estar en ejecución un Replay job de Account Activity Replay API por webhook a la vez.
¿Cómo puedo diferenciar los eventos de Account Activity Replay API de los eventos de producción en tiempo real a medida que se entregan a mi webhook?
Dado que la Account Activity Replay API siempre entregará eventos del pasado, los eventos se pueden diferenciar de los eventos de producción en tiempo real en función de la marca de tiempo del evento.
¿Con qué rapidez puedo empezar a usar la Account Activity Replay API para volver a entregar una actividad que mi aplicación descartó o se perdió?
Una actividad pasa a estar disponible para su reentrega aproximadamente 10 minutos después de que se creó.
Guía para solucionar errores
-
Enterprise - Asegúrate de que las consumer keys y los access tokens que estás utilizando pertenezcan a una App de X que haya sido registrada para el uso de productos Enterprise. Si no tienes tus consumer keys y access tokens, o necesitas agregar tu App de X a la allowlist, ponte en contacto con tu account manager.
-
Si te autenticas con contexto de usuario, asegúrate de haber autorizado correctamente tu solicitud con los valores correctos para
oauth nonce, oauth_signature y oauth_timestamp.
-
Asegúrate de que tus access tokens tengan el nivel de permisos adecuado.
- En la pestaña ‘Keys and tokens’ del app dashboard, asegúrate de que tus access tokens tengan el nivel de permisos ‘Read, write, and direct messages’ permission level.
- Si el nivel de permisos de los tokens está configurado en algo menor que esto, ve a la pestaña ‘Permissions’, ajusta el permiso de acceso a ‘Read, write, and direct messages’ y luego vuelve a generar tus access tokens y secret desde la pestaña ‘Keys and tokens’.
-
Asegúrate de que tu URL esté formada correctamente.
- Ten en cuenta que
:env_name distingue entre mayúsculas y minúsculas.
-
Premium - Asegúrate de que tienes una cuenta de desarrollador aprobada antes de intentar realizar una solicitud a la API. También debes usar el :env_name correcto en la solicitud, que puedes configurar en la página de entornos de desarrollo.
-
Enterprise - Asegúrate de que tu gestor de cuenta te haya habilitado el acceso a la Account Activity API.
-
Asegúrate de haber configurado correctamente tu URI. Este error puede producirse si has introducido una URI incorrecta en tu solicitud.
Código 214 - La URL del webhook no cumple con los requisitos.
Código 214 - Alta latencia en la solicitud GET de CRC. Tu webhook debe responder en menos de 3 segundos.
- Esto significa que tu servidor es lento. Asegúrate de responder al CRC en un plazo máximo de 3 segundos.
Código 214 - Código de respuesta distinto de 200 durante la solicitud GET de CRC (es decir, 404, 500, etc.).
- Tu servidor está caído. Asegúrate de que tu servidor esté funcionando correctamente.
Código 214 - Ya se han creado demasiados recursos.
- Enterprise - Ya has usado todos tus webhooks. Utiliza el endpoint GET webhooks con cada una de tus Apps registradas para identificar en qué Apps están configurados tus webhooks.
- La App que estás utilizando con la API no tiene configurado el nivel de permiso adecuado para su access token y access token secret. Dirígete a la pestaña «Keys and tokens» en el panel de X apps y comprueba los niveles de permiso asignados a tu access token y access token secret. Si está configurado en cualquier valor distinto de «Read, write and Direct Messages», tendrás que ajustar la configuración en la pestaña «Permission» y regenerar tu access token y access token secret para aplicar la nueva configuración.
- Como alternativa, es posible que estés intentando registrar un webhook utilizando autenticación solo de App, lo cual no es compatible. Autentícate con contexto de usuario tal como se indica en las secciones de Referencia de la API para registrar un webhook para la Enterprise Account Activity API.
Índice de referencia de la Account Activity API
| |
|---|
| Purpose | Enterprise |
| Registra una URL de webhook / genera un webhook_id | POST
webhooks |
| Devuelve todas las URL de webhook y sus estados | GET
webhooks |
| Activa manualmente una comprobación de respuesta al desafío | PUT
webhooks/:webhook_id |
| Suscribe una aplicación a los eventos de una cuenta | POST
webhooks/:webhook_id/subscriptions/all |
| Devuelve el número de suscripciones activas actualmente | GET
subscriptions/count |
| Comprueba si un webhook está suscrito a una cuenta | GET
webhooks/:webhook_id/subscriptions/all |
| Devuelve una lista de suscripciones activas actualmente | GET
webhooks/:webhook_id/subscriptions/all/list |
| Elimina el webhook | DELETE
webhooks/:webhook_id |
| Desactiva una suscripción usando OAuth de 3 patas (EN DESUSO) | DELETE
webhooks/:webhook_id/subscriptions/all |
| Desactiva una suscripción usando OAuth solo para aplicaciones | DELETE
webhooks/:webhook_id/subscriptions/:user_id/all.json |
| Reenvía las actividades a un webhook | POST
replay/webhooks/:webhook_id/subscriptions/all |
API de actividad de cuentas empresariales
POST account_activity/webhooks
https://api.x.com/1.1/account_activity/webhooks.json
| |
|---|
| Formato de la respuesta | JSON |
| Requiere autenticación | Sí (contexto de usuario: todos los tokens de consumidor y de acceso) |
| Sujeto a límite de frecuencia | Sí |
| Solicitudes / ventana de 15 minutos (autenticación de usuario) | 15 |
| Compatibilidad con edición de Tweets | Todos los objetos de Tweet incluirán metadatos de edición de Tweet que describen el historial de ediciones del Tweet. Consulta la página “Aspectos fundamentales de las ediciones de Tweet” para obtener más detalles. |
| |
|---|
| url (obligatorio) | URL codificada del endpoint de callback. |
| Código HTTP | Mensaje |
|---|
| 200 | La URL del webhook está registrada en la aplicación proporcionada |
| 403 | Hay un error en tu solicitud. Consulta la sección de mensajes de error a continuación. |
Ejemplo de respuesta: éxito
_HTTP 200_
{
"id": "1234567890",
"url": "https://your_domain.com/webhook/twitter/0",
"valid": true,
"created_at": "2016-06-02T23:54:02Z"
}
| Código | Mensaje |
|---|
| 214 | La URL del webhook no cumple los requisitos. |
| 214 | Ya se han creado demasiados recursos. |
| 214 | La URL del webhook no cumple los requisitos. Token CRC o formato de respuesta JSON no válidos. |
| 214 | Alta latencia en la solicitud GET de CRC. El webhook debe responder en menos de 3 segundos. |
| 214 | Código de respuesta distinto de 200 durante la solicitud GET de CRC (por ejemplo, 404, 500, etc.). |
{
"errors": [
{
"code": 214,
"message": "Too many resources already created."
}
]
}
GET account_activity/webhooks
URL del recurso
https://api.x.com/1.1/account_activity/webhooks.json
| |
|---|
| Formato de respuesta | JSON |
| Requiere autenticación | Sí (solo App - Bearer Token) |
| Con límite de uso | Sí |
| Solicitudes / ventana de 15 minutos (autenticación de App) | 15 |
Ejemplo de solicitud
$ curl --request GET
--url https://api.x.com/1.1/account_activity/webhooks.json
--header 'authorization: Bearer TOKEN'
[
{
"id": "1234567890",
"url": "https://your_domain.com/webhook/twitter/0",
"valid": true,
"created_at": "2016-06-02T23:54:02Z"
}
{
"id": "2468013579",
"url": "https://your_domain2.com/webhook/twitter/0",
"valid": true,
"created_at": "2016-06-04T22:31:29Z"
}
]
Mensajes de error
| Código | Mensaje |
|---|
| 99 | No tienes acceso a este recurso. |
PUT account_activity/webhooks/:webhook_id
valid.
URL del recurso
https://api.x.com/1.1/account_activity/webhooks/:webhook_id.json
| |
|---|
| Formato de respuesta | JSON |
| Requiere autenticación | Sí (contexto de usuario: todos los tokens de consumidor y de acceso) |
| Con límite de frecuencia | Sí |
| Solicitudes / ventana de 15 minutos (autenticación de usuario) | 15 |
Parámetros
| |
|---|
| webhook_id (required) | ID del webhook. Se define en la ruta del recurso. |
Ejemplo de solicitud
$ curl --request PUT
--url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID.json
--header 'authorization: OAuth oauth_consumer_key="CONSUMER_KEY", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="ACCESS_TOKEN", oauth_version="1.0"'
Mensajes de error
| Código | Mensaje |
|---|
| 34 | El webhook no existe o está asociado con una aplicación de X distinta. |
| 214 | La URL del webhook no cumple los requisitos. |
| 214 | La URL del webhook no cumple los requisitos. Token CRC o formato de respuesta JSON no válidos. |
| 214 | Alta latencia en la solicitud GET de CRC. Tu webhook debe responder en menos de 3 segundos. |
| 214 | Código de respuesta distinto de 200 durante la solicitud GET de CRC (por ejemplo, 404, 500, etc.). |
POST account_activity/webhooks/:webhook_id/subscriptions/all
URL del recurso
https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/all.json
| |
|---|
| Formato de respuesta | JSON |
| Requiere autenticación | Sí (OAuth de 3 participantes: clave de consumidor en lista de permitidos y token de acceso del usuario suscriptor) |
| Con límite de frecuencia | Sí |
| Solicitudes / ventana de 15 min (autenticación de usuario) | 500 |
| |
|---|
| webhook_id (requerido) | Identificador del webhook. Definido en la ruta del recurso. |
Ejemplo de solicitud
$ curl --request POST
--url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID/subscriptions/all.json
--header 'authorization: OAuth oauth_consumer_key="WHITELISTED_CONSUMER_KEY", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="SUBSCRIBING_USER'S_ACCESS_TOKEN", oauth_version="1.0"'
Respuesta de ejemplo - satisfactoria
Mensajes de error
| Código | Mensaje |
|---|
| 34 | El webhook no existe o está asociado a otra aplicación de X. |
| 348 | La aplicación cliente no tiene permiso para acceder a las suscripciones de webhooks de este usuario. |
GET account_activity/subscriptions/count
URL del recurso
https://api.x.com/1.1/account_activity/subscriptions/count.json
| |
|---|
| Formato de respuesta | Código de respuesta HTTP |
| Requiere autenticación | Sí (solo App - Bearer Token) |
| Con límite de frecuencia | Sí |
| Solicitudes por ventana de 15 minutos (autenticación de App) | 15 |
Códigos de respuesta HTTP
| |
|---|
| Code | Mensaje |
| 200 | Correcto. Se devolverá el número de suscripciones del webhook solicitado. |
| 401 | Tu aplicación no tiene permiso para ver las suscripciones del webhook especificado. |
Ejemplo de solicitud
$ curl --request GET
--url https://api.x.com/1.1/account_activity/subscriptions/count.json
--header 'authorization: Bearer TOKEN'
Ejemplo de respuesta - éxito
HTTP 200
{
"account_name":"my-account",
"subscriptions_count_all":"1",
"subscriptions_count_direct_messages":"0",
"provisioned_count":"50"
}
Mensajes de error
| Código | Mensaje |
|---|
| 32 | No se pudo autenticar tu identidad. |
{
"errors": [
{
"code": 32,
"message": "Could not authenticate you."
}
]
}
GET account_activity/webhooks/:webhook_id/subscriptions/all
https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/all.json
| |
|---|
| Formato de respuesta | JSON |
| Requiere autenticación | Sí (OAuth de 3 partes: clave de consumidor en lista de permitidos y token de acceso del usuario suscriptor) |
| Con límite de frecuencia | Sí |
| Solicitudes / ventana de 15 minutos (autenticación de usuario) | 500 |
| |
|---|
| webhook_id (required) | Identificador de webhook. Definido en la ruta del recurso. |
Ejemplo de solicitud
$ curl —request GET
—url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID/subscriptions/all.json
—header ‘authorization: OAuth oauth_consumer_key=“WHITELISTED_CONSUMER_KEY”, oauth_nonce=“GENERATED”, oauth_signature=“GENERATED”, oauth_signature_method=“HMAC-SHA1”, oauth_timestamp=“GENERATED”, oauth_token=“SUBSCRIBING_USER’S_ACCESS_TOKEN”, oauth_version=“1.0“‘
Ejemplo de respuesta - Éxito
HTTP 204 SIN CONTENIDO
GET account_activity/webhooks/:webhook_id/subscriptions/all/list
https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/all/list.json
| |
|---|
| Formato de la respuesta | Código de respuesta HTTP |
| Requiere autenticación | Sí (solo aplicación - Bearer Token) |
| Sujeto a límites de frecuencia | Sí |
| Solicitudes / ventana de 15 min (autenticación de la aplicación) | 50 |
| |
|---|
| webhook_id (required) | ID del webhook. Definido en la ruta del recurso. |
Códigos de respuesta HTTP
| Código | Mensaje |
|---|
| 200 | Éxito. Se devolverá una lista de suscripciones del webhook solicitado. |
| 401 | Tu aplicación no tiene permisos para ver las suscripciones del webhook especificado. |
Ejemplo de solicitud
$ curl —request GET
—url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID/subscriptions/all/list.json
—header ‘authorization: Bearer TOKEN’
Ejemplo de respuesta - correcta
HTTP 200
{
"webhook_id": "1234567890",
"webhook_url": "https://your_domain.com/webhook/twitter/0",
"application_id": "11231812",
"subscriptions": [{
"user_id": "20212306"
}]
}
Mensajes de error
| Code | Message |
|---|
| 32 | No se pudo autenticar tu cuenta. |
{
"errors": [
{
"code": 32,
"message": "Could not authenticate you."
}
]
}
DELETE account_activity/webhooks/:webhook_id
https://api.x.com/1.1/account_activity/webhooks/:webhook_id.json
| |
|---|
| Formato de respuesta | JSON |
| Requiere autenticación | Sí (contexto de usuario: todos los tokens de consumidor y de acceso) |
| Con límite de frecuencia | Sí |
| Solicitudes / ventana de 15 min (autenticación de usuario) | 15 |
| |
|---|
| webhook_id (obligatorio) | Identificador del webhook. Definido en la ruta del recurso. |
Ejemplo de solicitud
$ curl --request DELETE
--url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID.json
--header 'authorization: OAuth oauth_consumer_key="CONSUMER_KEY", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="ACCESS_TOKEN", oauth_version="1.0"'
Respuesta
HTTP 204 OK
DELETE account_activity/webhooks/:webhook_id/subscriptions/all (OBSOLETO)
https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/all.json
| |
|---|
| Formato de respuesta | JSON |
| Requiere autenticación | Sí (OAuth de 3 partes: consumer key en lista blanca y access token del usuario suscrito) |
| Con límite de frecuencia | Sí |
| Solicitudes / ventana de 15 minutos (autenticación de usuario) | 500 |
| |
|---|
| webhook_id (required) | Identificador del webhook. Definido en la ruta del recurso. |
Ejemplo de solicitud
$ curl --request DELETE
--url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID/subscriptions/all.json
--header 'authorization: OAuth oauth_consumer_key="WHITELISTED_CONSUMER_KEY", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="SUBSCRIBED_USER'S_ACCESS_TOKEN", oauth_version="1.0"'
DELETE /account_activity/webhooks/:webhook_id/subscriptions/:user_id/all.json
https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/:user_id/all.json
| |
|---|
| Formato de respuesta | JSON |
| Requiere autenticación | Sí (solo App - Bearer Token) |
| Sujeto a límite de frecuencia | Sí |
| Solicitudes por ventana de 15 minutos | 500 |
Ejemplo de solicitud
$ curl --request DELETE
--url https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/:user_id/all.json
--header 'authorization: Bearer TOKEN'
Respuesta
HTTP 204 NO CONTENT
| Código | Mensaje |
|---|
| 404 | Lo sentimos, esa página no existe. - Esto suele ocurrir cuando el id de usuario especificado en realidad no está suscrito. |
| |
|---|
| Request Method | HTTP POST |
| URL | /1.1/account_activity/replay/webhooks/:webhook_id/subscriptions/all.json?from_date=yyyymmddhhmm&to_date=yyyymmddhhmm |
| Response Format | JSON |
| Requires Authentication | Sí (solo aplicación - Bearer Token) |
| Rate Limit | 5 solicitudes cada 15 minutos. Actualmente no existe un límite máximo para la cantidad de jobs de replay que se pueden solicitar. |
| from_date | La marca de tiempo UTC más antigua (inicial) a partir de la cual se proporcionarán los eventos; debe estar en el formato ‘yyyymmddhhmm’. La marca de tiempo tiene granularidad de minutos y es inclusiva (es decir, 12:00 incluye el minuto 00). Las horas válidas deben estar dentro de los últimos 5 días, en hora UTC, y no ser más recientes que 31 minutos antes del momento actual. Se recomienda que from_date y to_date estén dentro de un intervalo de aproximadamente 2 horas. |
| to_date | La marca de tiempo UTC más reciente (final) hasta la cual se proporcionarán los eventos; debe estar en el formato ‘yyyymmddhhmm’. La marca de tiempo tiene granularidad de minutos y es exclusiva (es decir, 12:30 no incluye el minuto 30 de la hora). Las horas válidas deben estar dentro de los últimos 5 días, en hora UTC, y no ser más recientes que 10 minutos antes del momento actual. |
| Status | Text | Error Code | Description | Message |
|---|
| 202 | Accepted | N/A | La solicitud se realizó correctamente y se enviarán las actividades. | N/A |
| 400 | Bad Request | 214 | El webhook se ha marcado como no válido. | El webhook está marcado como no válido y requiere una verificación CRC. |
| 400 | Bad Request | 357 | Falta un parámetro de consulta. | : queryParam es obligatorio. |
| 400 | Bad Request | 358 | La ruta o el parámetro de consulta tiene un formato incorrecto. | No se puede analizar el parámetro. |
| 400 | Bad Request | 360 | El parámetro de ruta es negativo. | webhook_id: [] no es mayor o igual que 0. |
| 400 | Bad Request | 368 | from_date o to_date no está en el pasado. | : [<field_value>] no está en el pasado. |
| 400 | Bad Request | 356 | from_date debe ser anterior a to_date. | from_date debe ser anterior a to_date. |
| 400 | Bad Request | 356 | from_date debe estar dentro de los últimos 5 días. | from_date debe estar dentro de los últimos 5 días. |
| 401 | Unauthorized | 32 | La autenticación HTTP falló porque se proporcionó autenticación OAuth de 3 patas (3-legged OAuth). | Método de autenticación no válido. Usa únicamente autenticación de aplicación. |
| 401 | Unauthorized | 61 | El Client no tiene permiso para solicitar este método. | El Client no tiene permiso para solicitar este método. |
| 403 | Forbidden | 200 | El Client no tiene una cuenta empresarial con Replay habilitado. | Se requiere una cuenta empresarial de Account Activity API con Replay. Confirma que tienes una cuenta empresarial y que Replay está habilitado. |
| 404 | Not Found | 34 | webhook_id inexistente; desajuste entre webhook_id y application_id. | El webhook no existe o está asociado con una aplicación de X diferente. |
| 409 | Conflict | 355 | Hay una solicitud en curso y deberá terminar de procesarse antes de realizar otra. | Ya hay un trabajo de Replay en curso para este webhook. |
| 429 | Too Many Requests | 88 | Límite de frecuencia alcanzado (se alcanzó el límite del número de solicitudes por período de tiempo). | Demasiadas solicitudes. Reduce la frecuencia de tus solicitudes a la API. |
| 500 | Internal Server Error | 0 | Error interno del servidor. | Error interno del servidor. |
| 503 | Service Unavailable | 67 | Uno o más servicios dependientes en X no están disponibles. | Error del servidor de X. Reintenta usando un patrón de reintentos exponenciales. |
Mensaje de “Job completed successfully”
{
"replay\_job\_status": {
"webhook_id": "1234577122340233217",
"job_state": "Complete",
"job\_state\_description": "Job completed successfully"
"job_id": "1095098195724558337"
}
}
Mensaje “Job failed to complete”
{
"replay\_job\_status": {
"webhook_id": "123451374207332352",
"job_state": "Incomplete",
"job\_state\_description": "Job failed to deliver all events, please retry your replay job",
"job_id": "1093226942650736640"
}
}
Ejemplo de solicitud con curl
curl --request POST --url 'https://api.x.com/1.1/account_activity/replay/webhooks/:webhook_id/subscriptions/all.json?from_date=yyyymmddhhmm&to_date=yyyymmddhhmm'
--header 'authorization: Bearer TOKEN'
Ejemplo de respuesta
HTTP 202
{
"job_id": "1234567890",
"created_at": "2016-06-02T23:54:02Z"
}
