Este endpoint se ha actualizado para incluir metadata de edición de Posts. Obtén más información sobre esta metadata en la página de fundamentos “Edit Posts”. Este endpoint se usa con frecuencia junto con los endpoints de Mensajes Directos. Hemos lanzado nuevos endpoints de Mensajes Directos v2. Ten en cuenta que las Account Activity APIs de Enterprise y Premium admiten mensajes uno a uno en v2, pero aún no admiten conversaciones grupales. Enterprise
La Account Activity API te permite suscribirte a actividades en tiempo real relacionadas con una cuenta de usuario mediante webhooks. Esto significa que puedes recibir Posts, Mensajes Directos y otros eventos de cuenta en tiempo real desde una o más de tus cuentas propias o suscritas a través de una única conexión.
Recibirás todas las actividades relacionadas a continuación para cada suscripción de usuario en tu registro de webhook:
| Tipos de actividad | |
|---|
* Posts (del usuario)
* Eliminaciones de Post (del usuario)
* @menciones (del usuario)
* Respuestas (hacia o del usuario)
* Retweets (del usuario o sobre el usuario)
* Quote Tweets (del usuario o sobre el usuario)
* Retweets de Quote Tweets (del usuario o sobre el usuario)
* Likes (del usuario o sobre el usuario)
* Follows (del usuario o hacia el usuario)
* Unfollows (del usuario) | * Bloqueos (del usuario)
* Desbloqueos (del usuario)
* Silenciamientos (del usuario)
* Anulaciones de silenciamiento (del usuario)
* Mensajes Directos enviados (por el usuario)
* Mensajes Directos recibidos (por el usuario)
* Indicadores de escritura (hacia el usuario)
* Confirmaciones de lectura (hacia el usuario)
* Revocaciones de suscripción (del usuario) |
Ten en cuenta - No entregamos datos de la cronología de inicio mediante la Account Activity API. Utiliza GET statuses/home_timeline para obtener estos datos.
Consulta nuestra serie de videos en cuatro partes sobre la Account Activity API para ponerte al día.
Resumen de características
-
¿Tiene preguntas? ¿Está encontrando errores?
-
Explore nuestro código de muestra:
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 indicada.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/
-
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"'
Gestión de usuarios suscritos:
Adding a subscription
Viewing subscriptions
Removing a subscription
Comenzaremos suscribiendo a un usuario para que recibas todos los tipos de eventos.Copia la siguiente solicitud cURL en tu línea de comandos tras actualizar lo siguiente:
-
Webhook ID
<:WEBHOOK_ID> p. ej., 1234567890
-
Nombre de la clave del consumidor
<CONSUMER_KEY> p. ej., xvz1evFS4wEEPTGEFPHBog
-
Access token del usuario suscriptor
<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"'
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 la cuenta
- Repetir actividades de la cuenta
-
¿Tienes preguntas? ¿Te encuentras con errores?
-
Explora nuestro Código de muestra:
Enterprise
Introducción a los webhooks
- Crea una X app con una cuenta de desarrollador aprobada desde el portal de desarrolladores. Si creas la App en nombre de tu empresa, se recomienda hacerlo 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 permissions de la página de tu App.
- En la pestaña “Keys and Access Tokens”, toma nota del Consumer Key (API Key) y del Consumer Token (API Secret) de tu App.
- En la misma pestaña, genera los Access Token and 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 la X API, revisa Obtaining Access Tokens. A medida que agregues cuentas para recibir eventos, las suscribirás utilizando los access tokens de esa cuenta.
- Toma nota del id numérico de tu App, como se ve en la página “Apps” del portal de desarrolladores. Cuando solicites acceso a Account Activity API, necesitarás este id de la App.
2. Obtener acceso a Account Activity API
3. Desarrollar la App consumidora de webhooks
-
Cree una aplicación web con una URL para usar como webhook y recibir eventos. Este es el endpoint implementado en su servidor que escucha los eventos de webhook entrantes de X.
-
Como se describe en nuestra guía Securing Webhooks, el 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.
-
Registre su URL de webhook. Deberá hacer una solicitud POST al endpoint /webhooks.json?url=. Cuando haga esta solicitud, X enviará una solicitud CRC a su aplicación web. Cuando un webhook se registra correctamente, la respuesta incluirá un webhook id. Este webhook id se necesita más adelante al realizar algunas solicitudes a la Account Activity API.
-
X enviará eventos de webhook de cuenta a la URL que registró. Asegúrese de que su aplicación web admita solicitudes POST para eventos entrantes. Estos eventos estarán codificados en JSON. Consulte AQUÍ para ver ejemplos de cargas JSON de webhooks.
-
Una vez que su aplicación web esté lista, el siguiente paso es agregar cuentas para las que desea recibir actividades. Al agregar (o eliminar) cuentas, realizará solicitudes POST haciendo referencia al id de la cuenta. Consulte nuestra guía sobre cómo agregar suscripciones para obtener más información.
4. Validar la configuración
- Para validar que su App y su webhook estén configurados correctamente, marque como favorito un Post publicado por una de las cuentas de X a las que su App está suscrita. Debería recibir un
favorite_events mediante una solicitud POST a la URL de su webhook por cada favorito que reciban sus suscriptores.
- Tenga en cuenta que la entrega de eventos puede tardar hasta 10 segundos en comenzar después de añadir una suscripción.
Notas importantes
-
Al registrar la URL de su webhook, su aplicación web debe autenticarse con su consumer token y secret y con el access token y secret del usuario 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 su aplicación web tenga constancia de los Mensajes Directos enviados desde otro cliente.
-
Tenga 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 tiene dos usuarios utilizando su aplicación web para Mensajes Directos en la misma conversación, su webhook recibirá dos eventos duplicados (uno por cada usuario). Su aplicación web debe contemplar esto.
-
Si tiene más de una aplicación web que comparta la misma URL de webhook y el mismo usuario asignado a cada aplicación, el mismo evento se enviará a su webhook varias veces (una por cada aplicación web).
-
En algunos casos, su webhook puede recibir eventos duplicados. Su aplicación de webhook debe tolerar esto y eliminar duplicados por id de evento.
-
No espere que una respuesta de Quick Reply siga inmediatamente 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.
-
Consulte el código de ejemplo:
-
Enterprise Account Activity API dashboard, una aplicación web en Node que muestra eventos de webhook usando el nivel Enterprise de la Account Activity API e incluye funcionalidad de Replay.
-
El chatbot SnowBot, una aplicación web en Ruby creada sobre las APIs de Account Activity y Mensajes Directos. Este repositorio incluye un script para ayudar a configurar los webhooks de la Account Activity API.
Las API basadas en webhooks de X ofrecen dos métodos para verificar la seguridad de su servidor de webhook:
- Las comprobaciones de desafío-respuesta permiten a X confirmar la titularidad de la aplicación web que recibe eventos de webhook.
- El encabezado de firma en cada solicitud POST le permite confirmar que X es el origen de los webhooks entrantes.
Comprobaciones de Desafío-Respuesta
crc_token. Cuando se reciba esa solicitud, su aplicación web debe generar un response_token cifrado a partir del parámetro crc_token y del Consumer Secret de su App (detalles a continuación). El response_token debe codificarse en JSON (vea el ejemplo a continuación) y devolverse en un plazo de tres segundos. Si tiene éxito, se devolverá un id de webhook.
Se enviará una CRC cuando registre su URL de webhook, por lo que implementar su código de respuesta de CRC es un primer paso fundamental. Una vez que su webhook esté establecido, X activará una CRC aproximadamente cada 24 horas desde la última vez que recibimos una respuesta satisfactoria. Su App también puede activar una CRC cuando sea necesario realizando una solicitud PUT con el id de su webhook. Activar una CRC es útil mientras desarrolla su aplicación de webhook, después de implementar código nuevo y reiniciar su servicio.
Se debe esperar que el crc_token cambie en cada solicitud CRC entrante y debe usarse como el mensaje en el cálculo, donde su 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 realizará:
- Cuando se registre una URL de webhook.
- Aproximadamente cada hora para validar tu URL de webhook.
- Puedes activar manualmente un CRC realizando una solicitud PUT. A medida que desarrolles tu cliente de webhook, deberías planificar activar manualmente el CRC mientras implementas tu respuesta de CRC.
Requisitos de la respuesta:
- Un hash HMAC SHA-256 codificado en Base64 creado a partir de
crc_token y el Consumer Secret de tu App.
- response_token válido y formato JSON.
- Latencia inferior a 3 segundos.
- Código de respuesta HTTP 200.
Bibliotecas HMAC específicas del lenguaje:
Ejemplo de generación de tokens 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 recibido 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 hash codificado en base64
response = {
'response\_token': 'sha256=' + base64.b64encode(sha256\_hash_digest)
}
# devuelve una respuesta JSON con el formato correcto
return json.dumps(response)
Ejemplo de respuesta JSON:
{
"response_token": "sha256=x0mYd8hz2goCTfcNAaMqENy2BFgJJfJOb4PdvTffpwg="
}
- AQUÍ encontrarás un ejemplo de un método de respuesta CRC escrito en Node/JS.
- AQUÍ encontrarás un ejemplo de un método de respuesta CRC escrito en Ruby (consulta generate_crc_response y la ruta /GET que recibe eventos CRC).
Al recibir una solicitud POST de X, enviar una solicitud GET para crear un webhook o enviar una solicitud GET para realizar un CRC manual, se incluirá una firma de hash en los encabezados como x-twitter-webhooks-signature. Esta firma puede usarse para validar que la fuente de los data es X. La firma de hash de POST comienza con sha256=, lo que indica el uso de HMAC SHA-256 para proteger tu X App Consumer Secret y el payload. El hash de GET se calcula a partir de la cadena del parámetro query crc_token=token&nonce=nonce.
Pasos para validar una solicitud
- Crea un hash usando tu consumer secret y el cuerpo del payload entrante.
- Compara el hash creado con el valor x-twitter-webhooks-signature codificado en base64. Usa un método como compare_digest para reducir la vulnerabilidad a ataques por 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
- Calificación “A” en la prueba de ssllabs.com
- Habilitar TLS 1.2
- Habilitar Forward Secrecy
- Desactivar SSLv2
- Desactivar SSLv3 (por POODLE)
- Desactivar TLS 1.0
- Desactivar TLS 1.1
- Desactivar la compresión de TLS
- Desactivar los Session Tickets a menos que rote las claves de Session Tickets.
- Establecer la opción “ssl_prefer_server_ciphers” o “SSLHonorCipherOrder” en la configuración de SSL en “on”.
- Asegúrese 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
Gestión de webhooks y suscripciones
Creación y modificación de webhooks
Endpoints de gestión de configuración de webhooks:
¿Por qué no puedo simplemente actualizar la URL del webhook?
Agregar y eliminar suscripciones de usuarios
Endpoints de gestión de suscripciones
Tenga en cuenta: X debe habilitar el acceso a la Account Activity API para su App de desarrollador antes de que pueda comenzar a usar la API. Para ello, asegúrese de compartir el id de la App que piensa usar para la autenticación con su account manager o con el equipo de soporte técnico.
- Consumer Keys (API Key y Secret)
- Access Tokens (Access Token y Secret)
En el caso de los siguientes tres endpoints, realiza acciones de escritura dentro del contexto de su aplicación (no intervienen usuarios de X). Por lo tanto, los Access Tokens que debe proporcionar son los que pertenecen a su App de desarrollador. Estos pueden generarse directamente desde el portal de desarrolladores, en la pestaña “Keys and tokens” de su 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 información protegida 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 mediante el flujo de OAuth de 3 fases (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. Necesitarás regenerar 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 comenzar 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 equipo de soporte técnico.
- 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 en el contexto de su aplicación (no se involucran usuarios de X). Por lo tanto, los Access Tokens que debe proporcionar son los que pertenecen a su App de desarrollador. Estos se pueden generar directamente desde el portal de desarrolladores, en la pestaña “Keys and tokens” de su App.
Por otro lado, en el caso de los siguientes tres endpoints, se realiza una solicitud que permite a su aplicación acceder a datos protegidos en nombre de un usuario de X (por ejemplo, Mensajes Directos). Por lo tanto, debe proporcionar los Access Tokens que pertenecen al usuario suscriptor en cuestión. Los Access Tokens requeridos pueden obtenerse mediante el flujo de OAuth de 3 fases (consulte OAuth 1.0a: how to obtain a user’s Access Tokens). Estos endpoints se han marcado con un asterisco en la tabla anterior (*).
Tenga en cuenta: Asegúrese de que su App de desarrollador esté habilitada para “Read, Write, and Direct Messages.” Puede cambiar esta configuración en la sección Projects & Apps de su cuenta de desarrollador, en “App permissions” para la App de desarrollador seleccionada. Deberá regenerar las credenciales de su 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 “éxito”, el servidor de X iniciará un mecanismo de reintento y reenviará el evento de webhook hasta tres veces en un período de cinco minutos. Este servicio de reintentos de eventos de webhook ayuda a garantizar la confiabilidad y la recuperación de eventos cuando se producen problemas de red y durante interrupciones y despliegues del servicio del lado del cliente.
La Account Activity API ofrece una función de reintento cuando la app web del cliente no devuelve una respuesta 200 “success” para un evento de webhook de actividad de cuenta. Cuando el 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 respuesta en un plazo de tres segundos o no recibimos ninguna respuesta, reintentamos la solicitud y la dejamos 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 tu URL de webhook. En caso de que tu servidor no responda o devuelva un error transitorio, reintentaremos durante cinco minutos. Habrá un total de tres intentos de reintento para confirmar la validación. Esto proporciona redundancia y asegura que recibas 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 Account Activity API.
La Account Activity API intentará nuevamente hasta tres veces en un período de cinco minutos, hasta que se reciba una respuesta 200. Consulte la tabla a continuación para más detalles. Después de aproximadamente cinco minutos, la actividad no puede volver a enviarse a través de la Account Activity API. Deberá usar otros endpoints de X para recopilar data omitida. Por ejemplo, las search APIs pueden utilizarse para recuperar Posts, Retweets, Quote Tweets, menciones y respuestas. Los Mensajes Directos omitidos pueden recuperarse con este endpoint.
|
|---|
| Actividad creada; se envía un POST a la URL del webhook desde Account Activity API y expira en tres segundos. |
| Esperar tres segundos después de que finalice el tiempo de espera anterior; luego enviar un POST a la URL del webhook desde Account Activity API y expira en tres segundos. |
| Esperar 27 segundos después de que finalice el tiempo de espera anterior; luego enviar un POST a la URL del webhook desde Account Activity API y expira en tres segundos. |
| Esperar 242 segundos después de que finalice el tiempo de espera anterior; luego enviar un POST a la URL del webhook desde Account Activity API y expira en tres segundos. |
| Account Activity API dejará de intentar realizar POST después de esto. El cliente debe usar otros endpoints de X para recuperar los datos. |
Estructura del objeto de datos de Account Activity
| Objeto | Detalles |
|---|
| for_user_id | Identifica la suscripción de usuario a la que está relacionado 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 menciones en Posts. |
| source | El usuario que realiza 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 es seguido, bloqueado o silenciado es el usuario de destino. |
Actividades disponibles
| Tipo de mensaje | Detalles |
|---|
| tweet_create_events | Carga útil de estado de Post cuando el usuario de la suscripción realiza o recibe cualquiera de las siguientes acciones: Posts, Retweets, respuestas, @menciones, QuoteTweets, Retweet de Quote Tweets. |
| favorite_events | Evento de favorito (like) 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 | Evento de 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 en mensaje directo con el usuario y el destino. |
| direct_message_mark_read_events | Evento de marcado como leído de mensaje directo con el usuario y el destino. |
| tweet_delete_events | Aviso de Posts eliminados para facilitar el mantenimiento del cumplimiento. |
Ejemplos de carga útil
Consulta los ejemplos de carga útil a continuación para cada evento de Account Activity descrito en la tabla anterior.
{
"for_user_id": "2244994945",
"tweet_create_events": [
{
<Objeto Tweet>
}
]
}
{
"for_user_id": "2244994945",
"user_has_blocked": "false",
"tweet_create_events": [
{
<Objeto Tweet>
}
]
}
eventos_favoritos
{
"for_user_id": "2244994945",
"favorite_events": [{
"id": "a7ba59eab0bfcba386f7acedac279542",
"created_at": "Mon Mar 26 16:33:26 +0000 2018",
"timestamp_ms": 1522082006140,
"favorited_status": {
<Objeto Tweet>
},
"user": {
<Objeto de Usuario>
}
}]
}
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 >
}
]
}
}
block_events
{
"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": {
<Objeto de Usuario>
},
"target": {
<Objeto de Usuario>
}
}]
}
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 mías",
"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"
}
}
}
mensaje_directo_indicar_eventos_de_escritura
{
"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": "datos de día en @X, diseño al atardecer",
"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 las-opiniones-son-propias",
"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 la Cuenta
Enterprise
La API de Reproducción de Actividad de la Cuenta es una herramienta de recuperación de datos que permite obtener eventos de hasta cinco días atrás. Debe utilizarse para recuperar datos en escenarios en los que su servidor de webhook pierde eventos, ya sea por desconexiones que superan la ventana de reintento o en casos de recuperación ante desastres en los que necesita algunos días para restablecer su sistema a la normalidad.
La API de Reproducción de Actividad de la Cuenta se desarrolló para cualquier escenario en el que no se logren ingerir actividades durante un período de tiempo. Entrega las actividades al mismo webhook utilizado para la entrega original en tiempo real. Este producto es una herramienta de recuperación y no de relleno histórico (backfill), 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 la 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 y tipos de datos
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
Disponemos de nuevos endpoints y servicios que ofrecen un acceso similar y, en el caso de Mensajes Directos, funciones adicionales:
Para ayudarle a realizar una migración sin contratiempos a estos nuevos endpoints y servicios, contamos con dos guías de migración:
Además, contamos con una serie de videos sobre Account Activity API y cómo comenzar.
Y, por último, tenemos ejemplos de código para ampliar su comprensión y ayudarle a comenzar rápidamente:
- El Account Activity Dashboard es una App web de Node.js de ejemplo con scripts auxiliares para comenzar con Account Activity API.
- SnowBot es un chatbot de ejemplo que utiliza Account Activity API y los endpoints REST de Mensajes Directos. Está escrito en Ruby, usa el framework web Sinatra y se implementa en Heroku.
Guía de migración: de User Streams/Site Streams a Account Activity API
Diferencias y consideraciones de migración
Gestión de suscripciones de usuarios
Cómo realizar la migración
Siga 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 y proyectados gestionados en su aplicación
- Número actual de aplicaciones cliente de X
- El nivel de soporte que prefiere de X (soporte por foro o soporte gestionado Enterprise 1:1)
- Precio de cada paquete
Paso 2: Verifique la configuración de su X app en el portal de desarrolladores
La X app que se utiliza actualmente para User Streams o Site Streams aparecerá listada para el usuario propietario dentro del portal de desarrolladores. Esta X app también se puede usar para Account Activity API para conservar a los usuarios autorizados de esa aplicación. También se puede crear una nueva app, y los usuarios pueden volver a autorizarse para esta nueva app si se desea. Si está creando una nueva app en nombre de una empresa, se recomienda que cree la app con una cuenta corporativa X @handle.
- Habilite “Read, Write and Access direct messages” en la pestaña permissions de la página de su X app.
*Tenga en cuenta que cambiar estas configuraciones no es retroactivo; cualquier usuario autorizado conservará las configuraciones de autorización del momento en que fue autorizado. Si un usuario aún no le ha otorgado acceso de lectura, escritura y Mensajes Directos, deberá pedirle que vuelva a autorizar su aplicación.
- Si no está familiarizado con X Sign-in y cómo funcionan los contextos de usuario con la X API, revise Obtaining Access Tokens.
- Genere access tokens para el propietario de la X app al final de la pestaña “Keys and Tokens”. En esta misma pestaña, tome nota de su Consumer Key, Consumer Secret, Access Token y Access Token Secret. Los necesitará para usar la API.
- Genere un Bearer Token utilizando su Consumer Key y Consumer Secret para métodos de API application-only.
Paso 3: Configure sus webhooks
-
Cree una aplicación web con un endpoint para usar como webhook y recibir eventos (p. ej., https://your_domain.com/webhook/twitter o https://webhooks.your_domain.com).
-
Use su Consumer Key, Consumer Secret, Access Token y Access Token Secret al crear su webhook. Tenga en cuenta que su 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 su app.
-
Revise la documentación Securing Webhooks prestando especial atención a los requisitos de Challenge Response Check (CRC).
-
Asegúrese de que su webhook admita 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 Webhook APIs protegerán sus webhooks de dos maneras:
- Requerir verificaciones de respuesta de desafío para validar que el propietario del webhook sea el propietario de la aplicación web.
- Un encabezado de firma en cada solicitud POST para que su aplicación web valide el origen.
- Para verificar que usted sea 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 verificación de redundancia cíclica.
- Se enviará una solicitud GET con un parámetro llamado crc_token a la URL de su webhook. Su 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 su app.
- Se debe esperar que el crc_token cambie en cada solicitud CRC entrante. El crc_token debe utilizarse como el mensaje en el cálculo, donde su 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: Cree suscripciones para cada usuario autorizado de User Streams o Site Streams
Conversión a la Account Activity API desde User Streams:
- Genera una lista de tus suscripciones de usuario actuales en User Streams
- Configura tus nuevas suscripciones de Account Activity API con la solicitud: POST account_activity/all/:env_name/subscriptions
- Confirma tus suscripciones de Account Activity API con 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 con la solicitud: GET /1.1/site/c/:stream_id/info.json
- Configura tus nuevas suscripciones de Account Activity API con la solicitud: POST account_activity/all/:env_name/subscriptions
- Confirma tus suscripciones de Account Activity API con 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 actividad de la cuenta (aplicación de ejemplo de la Account Activity API)
- Descargue la aplicación de ejemplo Account Activity Dashboard aquí (usa Node.js)
- Siga las instrucciones del README para instalar e iniciar la App
- Una vez iniciada la aplicación, puede usar la interfaz para configurar fácilmente su webhook y crear una nueva suscripción
Tipos de mensajes de stream en desuso
| |
|---|
| 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 de 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 identificadores 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 saturación | Las advertencias de saturación ya no serán necesarias, ya que los webhooks no dependen de una conexión activa capaz de manejar grandes volúmenes de mensajes entrantes. |
| Lista de amigos | 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 un Post | delete | Usuario actual | Usuario actual | Post |
| Un usuario seguido elimina un Post | delete | Usuario seguido | Usuario seguido | Post |
| El usuario quita el favorito de un Post | unfavorite | Usuario actual | Autor del Post | Post |
| Se quita el favorito del Post del usuario | unfavorite | Usuario que quita el favorito | Usuario actual | Post |
| El usuario deja de seguir a alguien | unfollow | Usuario actual | Usuario seguido | Null |
| El usuario crea una List | list_created | Usuario actual | Usuario actual | List |
| El usuario elimina una List | list_destroyed | Usuario actual | Usuario actual | List |
| El usuario edita una List | list_updated | Usuario actual | Usuario actual | List |
| El usuario agrega a alguien a una List | list_member_added | Usuario actual | Usuario agregado | List |
| El usuario es agregado a una List | list_member_added | Usuario que agrega | Usuario actual | List |
| El usuario elimina a alguien de una List | list_member_removed | Usuario actual | Usuario eliminado | List |
| El usuario es eliminado de una List | list_member_removed | Usuario que elimina | Usuario actual | List |
| El usuario se suscribe a una List | list_user_subscribed | Usuario actual | Propietario de la List | List |
| La List del usuario recibe una suscripción | list_user_subscribed | Usuario suscriptor | Usuario actual | List |
| El usuario cancela la suscripción a una List | list_user_unsubscribed | Usuario actual | Propietario de la List | List |
| La List del usuario pierde una suscripción | list_user_unsubscribed | Usuario que cancela la suscripción | 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
- Compatibilidad con archivos multimedia adjuntos (imagen, GIF y video).
- Posibilidad de solicitar a los usuarios respuestas estructuradas con una lista de opciones predefinida.
- Acceso a los Mensajes Directos de hasta 30 días atrás.
Para obtener la lista completa de novedades de Mensajes Directos y 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 completamente nueva del objeto de Mensaje directo.
- Objeto de usuario simplificado.
- Nueva información disponible (respuestas de «quick reply», 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": "¡Hola Mundo!"}}}}'
- El mensaje se define en el cuerpo de la solicitud POST en formato JSON
- El encabezado Content-Type debe configurarse como application/json
- El cuerpo JSON no se incluye en la generación de la firma de OAuth.
Obtención de Mensajes Directos
- 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 mediante webhook.
Eliminación de Mensajes Directos
- Eliminar un Mensaje Directo requiere el id.
- El nuevo endpoint requiere una solicitud DELETE.
- La manera 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.
¿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 streaming APIs, no necesitas mantener una conexión abierta para que te enviemos información. Los webhooks también difieren de las Rest APIs porque no tienes que consultarnos 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 en el momento en que suceden.
La Account Activity API ofrece varias ventajas:
- Velocidad: entregamos datos a la velocidad de X.
- Simplicidad: entregamos todos los eventos de una cuenta mediante una única conexión de webhook. Las actividades entregadas en la API incluyen Posts, @menciones, respuestas, Retweets, Quote Tweets, Retweets of Quote Tweets, likes, Mensajes Directos enviados, Mensajes Directos recibidos, follows, bloqueos y silenciamientos.
- Escalabilidad: recibes todas las actividades de una cuenta que administras sin estar restringido por límites de velocidad ni topes de eventos.
La Account Activity API está disponible como oferta premium sandbox, premium de pago y Enterprise, para que puedas escalar a medida que necesites más cuentas por requisitos de cumplimiento o funcionalidades adicionales.
Para comenzar, descarga fragmentos de Código de muestra 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 Enterprise.
¿Cuál es la diferencia entre un entorno Premium y un webhook de Enterprise?
No hay diferencia. Cada entorno Premium tendrá su propio webhook_id.
Necesito un entorno de desarrollo, staging y producción para Account Activity API, ¿es posible?
¡Sí! Con los niveles de pago de Account Activity API (Premium de pago y Enterprise), 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 agregar varias apps cliente a una allowlist para mantener la autorización de tus usuarios actualmente autorizados.
¿Tienen guías paso a paso sobre cómo configurarse con la Account Activity API?
¡De hecho, sí!
-
Si recién comienzas, te recomendamos visitar 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 Account Activity y Direct Message APIs. Esta base de código incluye un script para ayudar a configurar los webhooks de Account Activity API.
¿Existe alguna forma de recuperar datos si nuestro sistema se cae por 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 7 días.
Sugerimos usar tus distintos webhooks o entornos como herramienta de redundancia, así como la Account Activity Replay API, para asegurarte de no perder ninguna actividad si uno de tus sistemas se cae.
¿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 comienzas con la autenticación de X, te recomendamos leer esta sección.
¿Qué es una verificació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 correcto. También puede ser utilizada por los desarrolladores para asegurarse de que los datos que reciben provienen de X. X enviará automáticamente un CRC a su URL de webhook una vez cada 24 horas, a partir de la última vez que se validó la URL del webhook. Su sistema debe responder con una respuesta válida en un plazo de 3 segundos para mantener la validación.
Visite nuestra página Securing webhooks para más detalles.
¿Hay algo que invalidaría inmediatamente mi URL de webhook?
Si ocurre alguno de los siguientes casos, marcaremos su webhook como no válido de inmediato:
- El servidor responde a un CRC con un token incorrecto. En este caso, nuestro sistema no reintentará enviarle la actividad.
- La URL del webhook tiene un certificado incorrecto configurado. En este caso, nuestro sistema no reintentará enviarle la actividad.
- Su servidor devuelve un código de respuesta que no es 2XX, 4XX ni 5XX.
- Especifica el uso de gzip sin enviarlo realmente.
- No especifica el uso de gzip, pero lo envía en la respuesta.
¿Recibiré actividades duplicadas si estoy suscrito a usuarios que interactúan entre sí?
Sí. Si su 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 este momento, 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 forma 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 gratuito. Nuestra opción de sandbox está limitada a un único webhook con un máximo de 15 suscripciones. Puede leer más sobre la opción de sandbox en nuestra documentación.
¿Es posible usar la Account Activity API para obtener Retweets de Posts que mencionen 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 alguna de las siguientes acciones:
- Crea un Post
- Hace un 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 le 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á 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 de Post.
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 ha añadido a una lista de permitidos para el acceso mediante las APIs de Enterprise, póngase en contacto con su gestor de cuenta e indique el id de su app. Puede encontrar el id de su app navegando a la página “Apps” en el portal de desarrolladores.
Si tengo acceso a tres webhooks, ¿puedo usar tres webhooks para cada una de las apps que he registrado para uso de Enterprise?
El límite de webhooks se establece a nivel de cuenta, no a nivel de app. Si tiene acceso a tres webhooks y dos apps registradas para uso de Enterprise, puede 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 reproducirán todos los eventos entregados durante la ventana de fecha y hora especificada.
¿Habrá reintentos si mi aplicación no logra ingerir un evento de la Account Activity Replay API?
No, no habrá reintentos. Si una aplicación no logra ingerir un evento enviado por la Account Activity Replay API, se puede enviar otro trabajo de Replay para el mismo período de tiempo con el fin de intentar la reentrega de cualquier evento de Replay omitido.
¿Qué debo hacer cuando recibo un evento de finalización con éxito parcial?
Sugerimos anotar las marcas de tiempo de los eventos recibidos y solicitar otro trabajo de Replay para los eventos que se omitieron.
¿Cuántos trabajos de la Account Activity Replay API puedo tener en ejecución a la vez?
Solo puede ejecutarse 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, estos pueden diferenciarse de los eventos de producción en tiempo real por 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 pasó por alto?
Una actividad está disponible para volver a entregarse aproximadamente 10 minutos después de su creación.
Guía para la resolución de errores
-
Enterprise - Asegúrate de que las consumer keys y los access tokens que estás usando pertenecen a una X App registrada para usar productos Enterprise. Si no cuentas con tus consumer keys y access tokens, o necesitas agregar tu X App a la allowlist, comunícate con tu account manager.
-
Si autenticas con contexto de usuario, asegúrate de haber autorizado tu solicitud correctamente con los
oauth_nonce, oauth_signature y oauth_timestamp adecuados.
-
Asegúrate de que tus access tokens tengan el nivel de permisos correcto.
- En la pestaña ‘Keys and tokens’ del app dashboard, verifica que tus access tokens tengan el nivel de permisos ‘Read, write, and direct messages’ permission level.
- Si el nivel de permisos de los tokens es inferior a esto, ve a la pestaña ‘Permissions’, ajusta el permiso de acceso a ‘Read, write, and direct messages’ y, luego, regenera tus access tokens y el secret desde la pestaña ‘Keys and tokens’.
-
Asegúrate de que tu URL esté correctamente formada.
- Ten en cuenta que
:env_name distingue entre mayúsculas y minúsculas.
-
Premium - Asegúrate de tener 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 dev environments.
-
Enterprise - Asegúrate de que tu gerente 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 ingresaste un URI incorrecto en tu solicitud.
Código 214 - La URL del webhook no cumple los requisitos.
Código 214 - Latencia alta 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 máximo de 3 segundos.
Código 214 - Código de respuesta distinto de 200 durante la solicitud CRC con GET (p. ej., 404, 500, etc.).
- Su servidor está caído. Asegúrese de que esté en ejecución correctamente.
Código 214 - Se han creado demasiados recursos.
- Enterprise - 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.
- La App que utiliza con la API no tiene configurado 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 volver a generar su access token y access token secret para aplicar la nueva configuración.
- Alternativamente, está intentando registrar un webhook usando autenticación solo de aplicación, lo cual no es compatible. Autentíquese con contexto de usuario según 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
Account Activity API de Enterprise
POST account_activity/webhooks
Registra una nueva URL de webhook para el contexto de la aplicación indicado. La URL se validará mediante una solicitud CRC antes de guardarse. Si la validación falla, se devolverá un mensaje de error detallado al solicitante.
El número de webhooks permitidos está determinado por el paquete de facturación.
https://api.x.com/1.1/account_activity/webhooks.json
| |
|---|
| Formato de respuesta | JSON |
| Requiere autenticación | Sí (context de usuario: todos los consumidores y access tokens) |
| Con límite de tasa | Sí |
| Solicitudes por ventana de 15 minutos (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. Consulte la página de fundamentos sobre “Tweet edits” para más detalles. |
| |
|---|
| url (obligatoria) | URL codificada del endpoint de callback. |
$ 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“‘
| Código HTTP | Mensaje |
|---|
| 200 | La URL del webhook está registrada para la App proporcionada |
| 403 | Se produjo un error en la solicitud. Consulta la sección de mensajes de error a continuación. |
Ejemplo de respuesta: correcto
_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 no válido o formato de respuesta JSON no válido. |
| 214 | Latencia elevada 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.). |
HTTP 403
{
"errors": [
{
"code": 214,
"message": "Se han creado demasiados recursos."
}
]
}
GET account_activity/webhooks
Devuelve todas las URL y sus statuses para la App indicada.
Marcamos una URL como inválida si falla la comprobación diaria de validación. Para volver a habilitarla, llama al endpoint de actualización.
https://api.x.com/1.1/account_activity/webhooks.json
| |
|---|
| Formato de la respuesta | JSON |
| Requiere autenticación | Sí (solo App; Bearer Token) |
| Con límite de tasa | Sí |
| Solicitudes por ventana de 15 min (autenticación de App) | 15 |
$ 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"
}
]
| Código | Mensaje |
|---|
| 99 | No tiene acceso a este recurso. |
PUT account_activity/webhooks/:webhook_id
Inicia la verificación de desafío-respuesta (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.
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 consumer y access tokens) |
| Límite de tasa | Sí |
| Solicitudes por ventana de 15 minutos (autenticación de usuario) | 15 |
| |
|---|
| webhook_id (obligatorio) | id del webhook. Definido en la ruta del recurso. |
$ 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"'
| Código | Mensaje |
|---|
| 34 | El webhook no existe o está asociado a una X App 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 elevada en la solicitud CRC mediante GET. Su webhook debe responder en menos de 3 segundos. |
| 214 | Código de respuesta distinto de 200 durante la solicitud CRC mediante GET (p. ej., 404, 500, etc.). |
POST account_activity/webhooks/:webhook_id/subscriptions/all
Suscribe la App indicada a todos los eventos del contexto de usuario proporcionado para todos los tipos de mensajes. Tras la activación, todos los eventos del usuario solicitante se enviarán al webhook de la aplicación mediante una solicitud POST.
Las suscripciones están actualmente limitadas según la configuración de su cuenta. Si necesita añadir más suscripciones, póngase en contacto con su gestor de cuenta.
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 etapas: consumer key autorizada por lista de permitidos y access token del usuario suscriptor) |
| Límite de tasa | Sí |
| Solicitudes por ventana de 15 minutos (autenticación de usuario) | 500 |
| |
|---|
| webhook_id (obligatorio) | id del webhook. Definido en la ruta del recurso. |
$ 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 - Correcto
| Código | Mensaje |
|---|
| 34 | El webhook no existe o está asociado a una X App diferente. |
| 348 | La aplicación 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 están activas actualmente en su cuenta. Tenga en cuenta que el endpoint /count requiere OAuth de solo aplicación, por lo que debe realizar las solicitudes usando un Bearer Token en lugar del contexto de usuario.
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 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á un recuento de suscripciones para el webhook solicitado. |
| 401 | Su App no tiene permisos para ver las suscripciones del webhook especificado. |
$ curl --request GET
--url https://api.x.com/1.1/account_activity/subscriptions/count.json
--header 'authorization: Bearer TOKEN'
Ejemplo de respuesta: correcto
{
"account_name":"mi-cuenta",
"subscriptions_count_all":"1",
"subscriptions_count_direct_messages":"0",
"provisioned_count":"50"
}
| 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
Proporciona una forma de determinar si una configuración de webhook está suscrita a los eventos del usuario indicado. Si el contexto de usuario proporcionado tiene una suscripción activa con la aplicación indicada, devuelve 204 OK. Si el código de respuesta no es 204, el usuario no tiene una suscripción activa. Consulta el código de respuesta HTTP y los mensajes de error a continuación para obtener más detalles.
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 patas: consumer key en lista blanca y access token del usuario suscriptor) |
| Límite de tasa | Sí |
| Solicitudes por ventana de 15 minutos (autenticación de usuario) | 500 |
| |
|---|
| 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’S_ACCESS_TOKEN”, oauth_version=“1.0“‘
Ejemplo de respuesta: éxito
GET account_activity/webhooks/:webhook_id/subscriptions/all/list
Devuelve una lista de las suscripciones vigentes de tipo All Activity para el webhook especificado. Tenga en cuenta que el endpoint /list requiere OAuth de solo aplicación, por lo que las solicitudes deben realizarse usando un Bearer Token en lugar de un contexto de usuario.
URL del recurso
https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/all/list.json
| |
|---|
| Formato de la respuesta | Código de respuesta HTTP |
| Requiere autenticación | Sí (solo App; Bearer Token) |
| Con límite de tasa | Sí |
| Solicitudes por ventana de 15 minutos (autenticación de App) | 50 |
| |
|---|
| 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 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/webhooks/:WEBHOOK_ID/subscriptions/all/list.json
—header ‘authorization: Bearer TOKEN’
Respuesta de ejemplo - Éxito
{
"webhook_id": "1234567890",
"webhook_url": "https://your_domain.com/webhook/twitter/0",
"application_id": "11231812",
"subscriptions": [{
"user_id": "20212306"
}]
}
| Código | Mensaje |
|---|
| 32 | No se pudo autenticar tu identidad. |
HTTP 401
{
"errors": [
{
"code": 32,
"message": "No se pudo autenticarte."
}
]
}
DELETE account_activity/webhooks/:webhook_id
Quita el webhook de la configuración de la App indicada. Puedes obtener el id del webhook haciendo una llamada a GET /1.1/account_activity/webhooks.
https://api.x.com/1.1/account_activity/webhooks/:webhook_id.json
| |
|---|
| Formato de respuesta | JSON |
| Requiere autenticación | Sí (context de usuario: todos los consumer tokens y access tokens) |
| Límite de tasa | Sí |
| Solicitudes por ventana de 15 minutos (autenticación de usuario) | 15 |
| |
|---|
| webhook_id (obligatorio) | id del webhook. Definido en la ruta del recurso. |
$ 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 (EN DESUSO)
Desactiva las suscripciones para el contexto de usuario y la App proporcionados. Tras la desactivación, ya no se enviarán al webhook URL los eventos del usuario que realiza la solicitud.
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 partes: clave de consumidor permitida y access token del usuario suscrito) |
| Límite de tasa | Sí |
| Solicitudes por ventana de 15 minutos (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"'
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, dejarán de enviarse a la URL del webhook todos los eventos del usuario solicitante. Tenga en cuenta que este endpoint requiere OAuth solo para la aplicación; por lo tanto, las solicitudes deben realizarse usando un Bearer Token en lugar de un contexto de usuario.
URL del recurso
https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/:user_id/all.json
| |
|---|
| Formato de respuesta | JSON |
| Requiere autenticación | Sí (solo App; Bearer Token) |
| Con límite de tasa | Sí |
| Solicitudes por ventana de 15 minutos | 500 |
$ curl --request DELETE
--url https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/:user_id/all.json
--header 'authorization: Bearer TOKEN'
| Código | Mensaje |
|---|
| 404 | Lo sentimos, esa página no existe. Esto suele ocurrir cuando el id del usuario especificado no está realmente suscrito. |
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 su webhook tiene suscripciones de usuario activas, también recibirá esos eventos de forma concurrente. Nota: realizamos un CRC antes de entregar los eventos de reproducción.
| |
|---|
| Método de la 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 - Bearer Token) |
| Límite de tasa | 5 solicitudes por 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 minutos y es inclusiva (es decir, 12:00 incluye el minuto 00). Los tiempos válidos deben estar dentro de los últimos 5 días (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 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). Los tiempos válidos deben estar dentro de los últimos 5 días (hora UTC) y no ser más recientes que 10 minutos antes del momento actual. |
La API puede devolver las siguientes respuestas. 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, debe resolver el error e intentarlo de nuevo.
| Estado | Texto | Código de error | Descripción | Mensaje |
|---|
| 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 el parámetro query. | : queryParam es obligatorio. |
| 400 | Bad Request | 358 | La ruta o el parámetro query 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ó debido a que se proporcionó autenticación de 3 patas. | Método de autenticación no válido. Use únicamente la autenticación de solo aplicación. |
| 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 Enterprise con Replay habilitado. | Se requiere una cuenta Enterprise de Account Activity API con Replay. Confirme que tiene una cuenta Enterprise y que Replay está habilitado. |
| 404 | Not Found | 34 | webhook_id no existente; discrepancia entre webhook_id y application_id. | El webhook no existe o está asociado a una X App 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 tasa alcanzado (se alcanzó el límite del número de solicitudes por período de tiempo) | Demasiadas solicitudes. Reduzca la tasa de 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. Vuelva a intentarlo usando un patrón de retroceso exponencial. |
Mensaje “Job completed successfully”
Una vez que tu trabajo se complete correctamente, la API de Account Activity Replay 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»
{
"replay\_job\_status": {
"webhook_id": "123451374207332352",
"job_state": "Incomplete",
"job\_state\_description": "El trabajo no pudo entregar todos los eventos, vuelva a intentar 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'
{
"job_id": "1234567890",
"created_at": "2016-06-02T23:54:02Z"
}
