Saltar al contenido principal
Tenga en cuenta Hemos lanzado una nueva herramienta de cumplimiento para X API v2 llamada batch compliance. Esta nueva herramienta le permite cargar grandes conjuntos de datos de ids de Post o de usuarios para recuperar su estado de cumplimiento y determinar qué datos requieren acción para llevar sus conjuntos de datos a cumplimiento.
Además, tanto batch compliance como el firehose de cumplimiento se han actualizado para admitir ediciones de Post. En el firehose de cumplimiento, se añadió un nuevo evento “tweet_edit”. Consulte la documentación de Compliance Data Objects para más detalles. Obtenga más información sobre cómo funciona el metadato de Edit Post en la página Fundamentals of Edit Posts.

​
Descripción general

Empresarial Uno de los valores fundamentales de X es defender y respetar la voz del usuario. Esto incluye respetar sus expectativas e intención cuando eliminan, modifican o editan el contenido que deciden compartir en X. Creemos que esto es de importancia crítica para la salud a largo plazo de una de las plataformas públicas de información en tiempo real más grandes del mundo. X pone el control en manos de sus usuarios, otorgando a las personas la capacidad de gestionar su propia experiencia en X. Creemos que los clientes empresariales que reciben datos de X tienen la responsabilidad de respetar las expectativas e intención de los usuarios finales. Para obtener más información sobre los tipos de eventos de cumplimiento que son posibles en la plataforma de X, consulta nuestro artículo Respetar la intención del usuario en X. Cualquier desarrollador o empresa que consuma datos de X a través de una API tiene la obligación de realizar todos los esfuerzos razonables para respetar los cambios en el contenido del usuario. Esta obligación se extiende a eventos del usuario como eliminaciones, modificaciones y cambios en las opciones de compartición (por ejemplo, cuando el contenido pasa a estar protegido o retenido). Esto también incluye cuando los usuarios editan sus Posts. Consulta el texto específico en la Política para Desarrolladores y/o tu Contrato de Datos de X para entender cómo esta obligación afecta tu uso de los datos de X. X ofrece las siguientes soluciones que proporcionan información sobre estos eventos de cumplimiento del usuario y si un Post o Usuario específico está disponible públicamente o no. A continuación se presenta una breve descripción de las soluciones y sus patrones generales de integración:

​
GET statuses/lookup y GET users/lookup

  • Formato: API REST. Consulta: GET statuses/lookup y GET users/lookup.
  • Estos endpoints siempre devuelven la versión más reciente de cualquier edición de Post. Todos los objetos Post que describen Posts creados después de la introducción de la función de edición incluirán metadatos de edición de Post. Esto aplica incluso para Posts que no fueron editados.
  • Para todos los Posts, las solicitudes realizadas más de 30 minutos después de su creación representarán el estado final de los Posts.
  • Entregan información de disponibilidad para Posts o Usuarios específicos, según lo defina quien realiza la llamada como parte de la solicitud a la API.
  • Pueden usarse para verificaciones puntuales ad hoc del estado de disponibilidad actual de un grupo específico de Posts/Usuarios.
  • Ideal para clientes que necesiten comprobar el estado actual de un Post o Usuario específico en un momento determinado.
  • Estas API proporcionan un mecanismo útil que pueden usar los clientes que necesiten comprobar la disponibilidad de una pieza de Contenido, por ejemplo, cuando:
    1. Se muestran Posts
    2. Se interactúa con uno o varios Posts o Usuarios de forma 1:1
    3. Se distribuye Contenido de X a un tercero mediante una descarga de archivos permitida
    4. Se almacenan Posts por períodos prolongados

​
Compliance Firehose (solo Empresarial)

  • Formato: API de transmisión. Consulta: Compliance Firehose.
  • Proporciona un flujo en tiempo real de actividades de cumplimiento en X. Estas actividades incluyen cuando se editan los Posts.
  • Puede usarse para mantener el estado de cumplimiento en un conjunto de datos almacenados a medida que se producen nuevos eventos de cumplimiento en la plataforma.
  • Ideal para clientes que consumen y almacenan grandes volúmenes de datos de X durante períodos prolongados.

​
Guías

​
Mejores prácticas de cumplimiento normativo

​
Recomendaciones y mejores prácticas

  • Cree esquemas de almacenamiento de datos que guarden el id numérico de Post y el id de Usuario: Los mensajes del Usuario requieren tomar medidas sobre todos los Posts de ese Usuario. Por lo tanto, dado que todos los mensajes de cumplimiento se entregan únicamente por id numérico, es importante diseñar esquemas de almacenamiento que mantengan la relación entre Post y Usuario basada en ids numéricos. Los consumidores de datos deberán supervisar los eventos de cumplimiento tanto por id de Post como por id de Usuario y poder actualizar el almacén de datos local según corresponda.
  • Cree esquemas que contemplen todos los estados de cumplimiento: Según cómo se gestionen las actividades de cumplimiento en distintas aplicaciones, puede ser necesario agregar otros metadatos al almacén de datos. Por ejemplo, los consumidores de datos pueden decidir agregar metadatos a una base de datos existente para facilitar la restricción de la visualización de contenido en países afectados por un mensaje status_withheld.
  • Manejo de eliminaciones de Retweet: Los Retweets son un tipo especial de Post en el que el mensaje original está anidado en un objeto dentro del Retweet. En este caso, hay dos ids de Post referenciados en un Retweet: el id del Retweet y el id del mensaje original (incluido en el objeto anidado). Cuando se elimina un mensaje original, se emite un mensaje de eliminación de Post para el id original. Los eventos de eliminación de Post normalmente desencadenan eventos de eliminación para todos los Retweets. Sin embargo, en algunos casos no todos se envían y los sistemas cliente deben tolerar eliminaciones de Retweet incompletas. La eliminación del id original debería ser suficiente para eliminar todos los Retweets posteriores. Es una buena práctica hacer referencia al id de Post original al almacenar Retweets y eliminar todos los Retweets referenciados al recibir eventos de eliminación de Post.

​
Objetos de cumplimiento de datos

​
API de Compliance Firehose

Los tipos de eventos de cumplimiento posibles incluyen eventos de Post (o “status”) y eventos de Usuario, para los cuales se describen varios tipos a continuación.   Tenga en cuenta:
  • Lea más sobre los estados de Usuario aquí y nuestra política para desarrolladores sobre Posts eliminados aquí.
  • El Compliance Firehose se ha actualizado para proporcionar eventos ‘tweet_edit’.
  • Varios eventos de eliminación, protección y suspensión de Usuario no son necesariamente permanentes y pueden alternar entre estados indefinidamente. Estos incluyen: user_delete, user_undelete, user_protect, user_unprotect y user_suspend, user_unsuspend.
  • Los eventos user_delete van seguidos de status_delete 30 días después solo si el usuario no ha elegido user_undelete su cuenta. Es posible que un user_delete sea revertido por el usuario y, por lo tanto, no se produzcan eliminaciones de todos sus Posts 30 días después.
  • user_suspend es una acción que permanece vigente a menos que el usuario esté sujeto a un evento user_unsuspend. No están sujetos a cambios en un período de 30 días.
Consulte la columna ‘Recommended Action’ para entender cómo procesar cada tipo de evento y respetar la privacidad e intención del usuario final.
Original Message TypeObjectPermanent (Yes/No)Recommended Action
deleteStatusYesEliminar el Post asociado.
status_withheldStatusYesSuprimir el Post asociado en los países específicos indicados en el mensaje status_withheld.
dropStatusNoRetirar el Post de la vista pública.
undropStatusNoEl status puede mostrarse nuevamente y tratarse como público.
tweet_editStatusYesRespetar y, cuando corresponda, mostrar la nueva edición.
user_deleteUserNoSuprimir o eliminar todos los Posts del usuario asociado.
user_undeleteUserNoTodos los Posts del usuario asociado pueden mostrarse nuevamente y tratarse como públicos.
user_protectUserNoSuprimir o eliminar todos los Posts del usuario asociado.
user_unprotectUserNoTodos los Posts del usuario asociado pueden mostrarse nuevamente y tratarse como públicos.
user_suspendUserNoSuprimir o eliminar todos los Posts del usuario asociado.
user_unsuspendUserNoTodos los Posts del usuario asociado pueden mostrarse nuevamente y tratarse como públicos.
scrub_geoUserYesEliminar todos los datos geográficos proporcionados por X para todos los Posts del usuario anteriores al Post especificado en el mensaje scrub_geo. Tenga en cuenta que los Posts posteriores de un usuario pueden contener datos geográficos que pueden usarse.
user_withheldUserYesSuprimir los Posts del usuario asociado en los países específicos indicados en el mensaje user_withheld.
deleteFavoriteYesEliminar el like/favorito asociado.

​
Ejemplos de payload

Consulta los ejemplos de payload a continuación para cada evento de cumplimiento descrito en la tabla anterior. Edición de Post 
{"tweet_edit":
   {
     "id": "1557445923210514432"
     "initial_tweet_id": "1557433858676740098",
     "edit_tweet_ids": ["1557433858676740098", "1557445923210514432"],
     "timestamp_ms": "1660155761384"
   }
 }
Eliminación de Post
{
  "delete": {
    "status": {
      "id": 601430178305220600,
      "id_str": "601430178305220608",
      "user_id": 3198576760,
      "user_id_str": "3198576760"
    },
    "timestamp_ms": "1432228155593"
  }
}
Publicación retenida
{
  "status_withheld": {
    "status": {
      "id": 601430178305220600,
      "id_str": "601430178305220608",
      "user_id": 3198576760,
      "user_id_str": "3198576760"
    },
    "withheld_in_countries": [
      "XY"
    ],
    "timestamp_ms": "1432228155593"
  }
}
Soltar
{
  "drop": {
    "status": {
      "id": 601430178305220600,
      "id_str": "601430178305220600",
      "user_id": 3198576760,
      "user_id_str": "3198576760"
    },
    "timestamp_ms": "1432228155593"
  }
}
Restaurar
{
  "undrop": {
    "status": {
      "id": 601430178305220600,
      "id_str": "601430178305220600",
      "user_id": 3198576760,
      "user_id_str": "3198576760"
    },
    "timestamp_ms": "1432228155593"
  }
}

​
Depurar datos geográficos

{
  "scrub_geo": {
    "user_id": 519761961,
    "up_to_status_id": 411552403083628540,
    "up_to_status_id_str": "411552403083628544",
    "user_id_str": "519761961",
    "timestamp_ms": "1432228180345"
  }
}
Eliminación del usuario
{
  "user_delete": {
    "id": 771136850,
    "timestamp_ms": "1432228153548"
  }
}
Restaurar usuario
{
  "user_undelete": {
    "id": 796250066,
    "timestamp_ms": "1432228149062"
  }
}
Usuario oculto
{
  "user_withheld": {
    "user": {
      "id": 1375036644,
      "id_str": "1375036644"
    },
    "withheld_in_countries": [
      "XY"
    ],
    "timestampMs": "2014-08-27T23:49:41.839+00:00"
  }
}
Protección del usuario
{
  "user_protect": {
    "id": 3182003550,
    "timestamp_ms": "1432228177137"
  }
}
Quitar protección de usuario
{
  "user_unprotect": {
    "id": 2911076065,
    "timestamp_ms": "1432228180113"
  }
}
Suspensión del usuario
{
  "user_suspend": {
    "id": 3120539094,
    "timestamp_ms": "1432228194217"
  }
}
Rehabilitación de la cuenta del usuario
{
  "user_unsuspend": {
    "id": 3293130873,
    "timestamp_ms": "1432228193828"
  }
}

​
Integración de Compliance Firehose

Compliance Firehose es una API de streaming en tiempo real que entrega eventos de cumplimiento que ocurren en la plataforma de X. Para comprender los eventos de cumplimiento y cómo se generan en X, consulta nuestro artículo Honoring User Intent on X. Es importante tener en cuenta que los eventos de Post y de Usuario se entregan de forma independiente y que cada uno debe procesarse por separado (es decir, la eliminación de un Post no implica un evento de Usuario y viceversa). Varios eventos de Usuario no son necesariamente permanentes y pueden alternar entre estados indefinidamente. Estos incluyen: user_delete, user_undelete, user_protect, user_unprotect, user_suspend y user_unsuspend. Los user_delete van seguidos de status_delete 30 días después solo si el usuario no ha elegido realizar user_undelete en su cuenta. Es posible que un user_delete sea revertido por el usuario y que, en consecuencia, 30 días después no se produzcan eliminaciones de todos sus Posts. El user_suspend es una acción que permanece vigente a menos que el usuario esté sujeto a un evento de user_unsuspend. Estos no están sujetos a cambios en un período de 30 días. Nunca es apropiado mostrar los eventos de cumplimiento directamente a los usuarios de tu software ni incorporarlos de otra manera en tus productos o experiencias de cliente. Están destinados únicamente a mantener el cumplimiento y respetar las acciones de los usuarios de X.

​
Integración con Compliance Firehose

Para integrar Compliance Firehose en su sistema, deberá crear una integración que pueda hacer lo siguiente:
  1. Establecer una conexión de streaming con cada partición de la API de streaming de Compliance Firehose
  2. Manejar altos volúmenes de datos: desacoplar la ingesta del flujo del procesamiento adicional mediante procesos asíncronos
  3. Reconectarse automáticamente a las particiones del flujo cuando se desconecte por cualquier motivo
  4. Procesar eventos de cumplimiento relevantes para los datos de Post y de Usuario que haya almacenado, de acuerdo con la guía presentada anteriormente

​
Respetar la intención del usuario en X

Creemos que respetar la privacidad y la intención de los usuarios de X es fundamental para la salud a largo plazo de una de las plataformas públicas de información en tiempo real más grandes del mundo. X pone los controles de privacidad en manos de sus usuarios, dándoles la capacidad de gestionar su propia experiencia en X. Como empresas que consumen datos de X, tenemos la responsabilidad colectiva de respetar la privacidad y las acciones de los usuarios finales para mantener este entorno de confianza y respeto. Hay diversas situaciones que pueden afectar a los Posts y a las cuentas de Usuario y que influyen en cómo se muestran en la plataforma. Las acciones que afectan la privacidad y la intención se definen tanto a nivel de Estado (Post) como a nivel de Usuario. Estas acciones incluyen:

​
Usuario

AcciónDescripción
Proteger cuentaUn usuario de X puede proteger o dejar de proteger su cuenta en cualquier momento. Las cuentas protegidas requieren la aprobación manual del titular para cada persona a la que se le permita ver los Posts de su cuenta. 
Para obtener más información, consulta Información sobre los Posts públicos y protegidos.
Eliminar cuentaUn usuario de X puede decidir eliminar su cuenta y todos los mensajes de estado asociados en cualquier momento. X conserva la información de la cuenta durante 30 días después de la eliminación por si el usuario decide anularla y reactivar su cuenta.
Limpiar datos de ubicaciónUn usuario de X puede eliminar en cualquier momento todos los datos de ubicación de Posts anteriores. Esto se conoce como “scrub geo”.
Suspender cuentaX se reserva el derecho de suspender cuentas que infrinjan las Reglas de X o si se sospecha que una cuenta ha sido hackeada o comprometida. Las suspensiones de cuentas solo pueden revertirse (quitar la suspensión) por X.
Retener cuentaX se reserva el derecho de restringir de forma reactiva el acceso a cierto contenido en un país específico de vez en cuando. Solo X puede levantar la condición de retenida de una cuenta. 
Para obtener más información, consulta Contenido retenido por país.

​
Estado

AcciónDescripción
Eliminar estadoUn usuario de X puede eliminar un estado en cualquier momento. Los estados eliminados no se pueden recuperar y se borran de forma permanente.
Retener estadoX se reserva el derecho de retener de forma reactiva el acceso a cierto contenido en un país específico en ocasiones. Un estado retenido solo puede dejar de estar retenido por X.
Para obtener más información, consulta Contenido retenido por país.

​
Seguimiento de cambios de usuario y estado

El estado de un usuario o de un estado puede cambiar en cualquier momento debido a alguna de las acciones anteriores, y esto afecta la forma en que se espera que los consumidores de X data traten la disponibilidad y la privacidad de todo el contenido asociado. Cuando se producen estas acciones, se envía un mensaje de cumplimiento correspondiente que indica que el estado de un estado o de un usuario ha cambiado.

​
Referencia de API

​
GET compliance/firehose

​
Métodos

MétodoDescripción
GET /compliance/:streamConectar al flujo de datos

​
Autenticación

Todas las solicitudes a la API Compliance Firehose deben usar Autenticación Básica HTTP, basada en una combinación válida de dirección de correo electrónico y contraseña que se utiliza para iniciar sesión en su cuenta en console.gnip.com. Las credenciales deben enviarse en el encabezado Authorization en cada solicitud.

​
GET /compliance/:stream

Establece una conexión persistente con el flujo de datos de Compliance firehose, a través del cual se entregarán los eventos de cumplimiento.
Request MethodHTTP GET
Connection TypeKeep-Alive
URLDisponible en la página de ayuda de la API del flujo en tu panel, y sigue la estructura siguiente:


https://gnip-stream.x.com/stream/compliance/accounts/:account_name/publishers/twitter/:stream_label.json?partition=1

Nota: El parámetro “partition” es obligatorio. Deberás conectarte a las 8 particiones, cada una con el 12,5% del volumen total, para consumir el flujo completo.
CompressionGzip. Para conectarte al flujo usando compresión Gzip, envía un encabezado Accept-Encoding en la solicitud de conexión. El encabezado debe verse así:

Accept-Encoding: gzip
Character EncodingUTF-8
Response FormatJSON. El encabezado de tu solicitud debe especificar el formato JSON para la respuesta.
Rate Limit10 solicitudes por 60 segundos.
Read TimeoutConfigura un tiempo de espera de lectura en tu cliente y asegúrate de que sea superior a 30 segundos.
Support for Tweet editsTodas las ediciones de un Tweet generan un evento de Compliance “tweet_edit”. Consulta la documentación de Compliance Data Objects para más detalles.
Example Curl Request La siguiente solicitud de ejemplo se realiza con cURL desde la línea de comandos: 
curl --compressed -v -uexample@customer.com "https://gnip-stream.x.com/stream/compliance/accounts/:account_name/publishers/twitter/:stream_label.json?partition=1"
Nota: la solicitud anterior solo se conecta a partition=1 del firehose de Compliance; deberás conectarte a las 8 particiones para consumir este flujo en su totalidad.

​
Códigos de respuesta

La API puede devolver las siguientes respuestas para estas solicitudes. La mayoría de los códigos de error se devuelven con una cadena con detalles adicionales en el cuerpo. Para respuestas distintas de 200, los clientes deben intentar reconectarse.
EstadoTextoDefinición
200CorrectoLa conexión se abrió correctamente y se enviarán nuevas actividades a medida que lleguen.
401No autorizadoLa Autenticación HTTP falló debido a credenciales no válidas. Inicia sesión en console.gnip.com con tus credenciales para asegurarte de que las estás usando correctamente en tu solicitud.
406No aceptableGeneralmente ocurre cuando tu cliente no incluye correctamente los encabezados para aceptar la codificación gzip del stream, aunque también puede darse en otras circunstancias. Contendrá un mensaje JSON similar a: “Esta conexión requiere compresión. Para habilitar la compresión, envía un encabezado ‘Accept-Encoding: gzip’ en tu solicitud y prepárate para descomprimir el stream a medida que se lea en el cliente.”
429Límite de solicitudes excedidoTu App ha superado el límite de solicitudes de conexión.
503Servicio no disponibleIncidencia en el servidor de X. Vuelve a conectarte usando un patrón de backoff exponencial. Si no se ha publicado ningún aviso sobre este problema en la X API Status Page, contacta con soporte.

​
Otras recomendaciones y buenas prácticas

  • Cree esquemas de almacenamiento de datos que conserven el id numérico de Tweet y el id de Usuario: Los mensajes de usuario requieren tomar acciones sobre todos los Tweets de ese usuario. Por lo tanto, dado que todos los mensajes de cumplimiento se entregan únicamente por id numérico, es importante diseñar esquemas de almacenamiento que mantengan la relación entre Tweet y Usuario basada en ids numéricos. Los consumidores de datos deberán monitorear los eventos de cumplimiento tanto por id de Tweet como por id de Usuario y poder actualizar el almacén de datos local de forma adecuada.
  • Cree esquemas que contemplen todos los estados de cumplimiento: Según cómo se aborden las actividades de cumplimiento en diversas aplicaciones, puede ser necesario agregar otros metadatos al almacén de datos. Por ejemplo, los consumidores de datos pueden decidir agregar metadatos a una base de datos existente para facilitar la restricción de la visualización de contenido en países afectados por un mensaje status_withheld.
  • Cómo manejar eliminaciones de Retweets: Los Retweets son un tipo especial de Tweet en el que el mensaje original está anidado en un objeto dentro del Retweet. En este caso, hay dos ids de Tweet referenciados en un Retweet: el id del Retweet y el id del mensaje original (incluido en el objeto anidado). Cuando se elimina un mensaje original, se emite un mensaje de eliminación de Tweet para el id original. No se emiten mensajes de eliminación posteriores para todos los Retweets. La eliminación del id original debería ser suficiente para eliminar todos los Retweets posteriores.