Please note

We have released a new compliance tool to X API v2 called batch compliance. This new tool allows you to upload large datasets of Post or user IDs to retrieve their compliance status in order to determine what data requires action in order to bring your datasets into compliance.

In addtion, both the batch compliance and the compliance firehose have been updated to support Post edits. For the compliance firehose, a new 'tweet_edit' event was added. See the Compliance Data Objects documentation for more details. Learn more about how Edit Post metadata works on the Edit Posts fundamentals page.



One of X's core values is to defend and respect the user’s voice. This includes respecting their expectations and intent when they delete, modify, or edit the content they choose to share on X. We believe that this is critically important to the long term health of one of the largest public, real-time information platforms in the world. X puts controls in the hands of its users, giving individuals the ability to control their own X experience. We believe that business consumers that receive X data have a responsibility to honor the expectations and intent of end users.

For more information on the types of compliance events that are possible on the X platform, reference our article, Honoring User Intent on X.

Any developer or company consuming X data via an API holds an obligation to use all reasonable efforts to honor changes to user content. This obligation extends to user events such as deletions, modifications, and changes to sharing options (e.g., content becoming protected or withheld). This also includes when users edit their Posts. Please reference the specific language in the Developer Policy and/or your X Data Agreement to understand how this obligation affects your use of X data.

X offers the following solutions that deliver information about these user compliance events and whether a specific Post or User is publicly available or not. A brief overview of the solutions and their general integration patterns is detailed below:

GET statuses/lookup and GET users/lookup

  • Format: REST API’s See: GET statuses/lookup and GET users/lookup.
  • These endpoints always return the latest version of any Post edits. All Post objects describing Posts created after the edit feature was introduced will include Post edit metadata. This is true even for Posts that were not edited. 
  • For all Posts, requests for Posts more than 30 minutes after they were created will represent the final state of all Posts. 
  • Deliver availability information for specific Posts or Users as defined by the caller as part of the API request.
  • May be used for ad-hoc spot-checking on the current availability state of a specific group of Posts / Users.
  • Ideal for customers who need a way to check the current state of a specific Post or User at a given moment in time.
  • These API’s provide a helpful mechanism that may be used by customers who need to check the availability of a piece of Content, for instance when:
    1. Displaying Posts
    2. Engaging with a Post(s) or User(s) in a 1:1 way
    3. Distributing X Content to a 3rd party through an allowed file download
    4. Storing Posts for extended periods of time

Compliance Firehose (enterprise only)

  • Format: Streaming API See: Compliance Firehose.
  • Delivers realtime stream of Compliance activities on X. These activities include when Posts are edited. 
  • May be used to maintain compliance state across a set of stored data as new compliance events happen on the platform.
  • Ideal for customers consuming and storing large quantities of X data for extended periods of time.