Compliance Firehose API

Ten en cuenta Hemos lanzado una nueva herramienta de cumplimiento para la X API v2 llamada batch compliance. Esta nueva herramienta te permite subir grandes conjuntos de datos de IDs de Posts o de usuarios para recuperar su estado de cumplimiento con el fin de determinar qué datos requieren acción para que tus conjuntos de datos cumplan con la normativa.

Además, tanto batch compliance como el compliance firehose se han actualizado para admitir ediciones de Posts. Para el compliance firehose, se ha añadido un nuevo evento ‘tweet_edit’. Consulta la documentación de Objetos de datos de cumplimiento para más detalles. Aprende más sobre cómo funcionan los metadatos de edición de Posts en la página Fundamentos de Editar Posts.

​

Descripción general

​

GET statuses/lookup y GET users/lookup

• Formato: APIs REST. Consulta: GET statuses/lookup y GET users/lookup.
• Estos endpoints siempre devuelven la última versión de cualquier edición de Post. Todos los objetos Post que describen Posts creados después de que se introdujera la funcionalidad de edición incluirán metadatos de edición de Posts. Esto es cierto incluso para Posts que no fueron editados.
• Para todos los Posts, las solicitudes de Posts más de 30 minutos después de su creación representarán el estado final de todos los Posts.
• Entregan información de disponibilidad para Posts o Usuarios específicos según los defina el llamante como parte de la solicitud de la API.
• Pueden usarse para comprobaciones ad-hoc del estado actual de disponibilidad de un grupo específico de Posts / Usuarios.
• Ideal para clientes que necesitan una forma de verificar el estado actual de un Post o Usuario específico en un momento dado.
• Estas APIs proporcionan un mecanismo útil que puede ser usado por clientes que necesitan verificar la disponibilidad de una pieza de contenido, por ejemplo cuando:
  1. Muestran Posts
  2. Interactúan con un Post(s) o Usuario(s) de forma 1:1
  3. Distribuyen contenido de X a un tercero a través de una descarga de archivo permitida
  4. Almacenan Posts durante períodos prolongados de tiempo

​

Compliance Firehose (solo enterprise)

• Formato: API de streaming. Consulta: Compliance Firehose.
• Entrega un stream en tiempo real de actividades de cumplimiento en X. Estas actividades incluyen cuando los Posts son editados.
• Puede usarse para mantener el estado de cumplimiento en un conjunto de datos almacenados a medida que ocurren nuevos eventos de cumplimiento en la plataforma.
• Ideal para clientes que consumen y almacenan grandes cantidades de datos de X durante períodos prolongados de tiempo.

​

Guías

​

Buenas prácticas de cumplimiento

​

Recomendaciones y buenas prácticas

• Construye esquemas de almacenamiento de datos que almacenen el Post ID y User ID numéricos: Los mensajes de usuario requieren que se tome acción en todos los Posts de ese usuario. Por lo tanto, dado que todos los mensajes de cumplimiento se entregan solo por ID numérico, es importante diseñar esquemas de almacenamiento que mantengan la relación entre Post y Usuario basándose en IDs numéricos. Los consumidores de datos necesitarán monitorizar eventos de cumplimiento tanto por Post ID como por User ID y ser capaces de actualizar el almacén de datos local apropiadamente.
• Construye esquemas que aborden todos los estados de cumplimiento: Dependiendo de cómo se aborden las actividades de cumplimiento en varias 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 los países afectados por un mensaje status_withheld.
• Manejo de eliminaciones de Retweets: Los Retweets son un tipo especial de Post donde el mensaje original está anidado en un objeto dentro del Retweet. En este caso, hay dos Post IDs 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 activan eventos de eliminación para todos los Retweets. Sin embargo, en algunos casos no se envían todos y los sistemas cliente deben tolerar eliminaciones incompletas de Retweets. La eliminación del ID original debería ser suficiente para eliminar todos los Retweets subsiguientes. Es una buena práctica referenciar el Post ID original al almacenar Retweets, y eliminar todos los Retweets referenciados al recibir eventos de eliminación de Post.

​

Objetos de datos de cumplimiento

​

Compliance Firehose API

• Lee más sobre los statuses de User aquí y nuestra política de desarrollador sobre Posts eliminados aquí.
• El Compliance Firehose se ha actualizado para proporcionar eventos ‘tweet_edit’.
• Varios eventos de user delete, protect y suspend no son necesariamente permanentes y pueden alternar entre estados infinitamente. Estos incluyen: user_delete, user_undelete, user_protect, user_unprotect y user_suspend, user_unsuspend.
• Los user_deletes son seguidos por status_deletes 30 días después solo si el usuario no ha seleccionado hacer user_undelete de su cuenta. Es posible que un user_delete sea revertido por el usuario y los deletes para todos sus Posts 30 días después no ocurran.
• User_suspend es una acción que permanece verdadera a menos que el usuario esté sujeto a un evento user_unsuspend. Estos no están sujetos a ningún cambio en un período de tiempo de 30 días.

​

Ejemplos de carga útil

{"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"
  }
}

Post retenido

Ejemplo de respuesta

{
  "status_withheld": {
    "status": {
      "id": 601430178305220600,
      "id_str": "601430178305220608",
      "user_id": 3198576760,
      "user_id_str": "3198576760"
    },
    "withheld_in_countries": [
      "XY"
    ],
    "timestamp_ms": "1432228155593"
  }
}

Drop

{
  "drop": {
    "status": {
      "id": 601430178305220600,
      "id_str": "601430178305220600",
      "user_id": 3198576760,
      "user_id_str": "3198576760"
    },
    "timestamp_ms": "1432228155593"
  }
}

Undrop

{
  "undrop": {
    "status": {
      "id": 601430178305220600,
      "id_str": "601430178305220600",
      "user_id": 3198576760,
      "user_id_str": "3198576760"
    },
    "timestamp_ms": "1432228155593"
  }
}

​

Scrub geo

{
  "scrub_geo": {
    "user_id": 519761961,
    "up_to_status_id": 411552403083628540,
    "up_to_status_id_str": "411552403083628544",
    "user_id_str": "519761961",
    "timestamp_ms": "1432228180345"
  }
}

User delete

{
  "user_delete": {
    "id": 771136850,
    "timestamp_ms": "1432228153548"
  }
}

User undelete

{
  "user_undelete": {
    "id": 796250066,
    "timestamp_ms": "1432228149062"
  }
}

User withheld

Ejemplo de respuesta

{
  "user_withheld": {
    "user": {
      "id": 1375036644,
      "id_str": "1375036644"
    },
    "withheld_in_countries": [
      "XY"
    ],
    "timestampMs": "2014-08-27T23:49:41.839+00:00"
  }
}

User protect

{
  "user_protect": {
    "id": 3182003550,
    "timestamp_ms": "1432228177137"
  }
}

User unprotect

{
  "user_unprotect": {
    "id": 2911076065,
    "timestamp_ms": "1432228180113"
  }
}

User suspend

{
  "user_suspend": {
    "id": 3120539094,
    "timestamp_ms": "1432228194217"
  }
}

User unsuspend

{
  "user_unsuspend": {
    "id": 3293130873,
    "timestamp_ms": "1432228193828"
  }
}

​

Integración del Compliance Firehose