How X (Twitter) Designed Its Home Timeline API: Lessons to Learn | by Oleksii Trekhleb | Dec, 2024

A better have a look at X’s API: fetching knowledge, linking entities, and fixing under-fetching.

When designing a system’s API, software program engineers usually consider numerous approaches, equivalent to REST vs RPC vs GraphQL, or hybrid fashions, to find out the very best match for a particular job or challenge. These approaches outline how knowledge flows between the backend and frontend, in addition to the construction of the response knowledge:

• Ought to all knowledge be packed right into a single “batch” and returned in a single response?
• Can the “batch” be configured to incorporate solely the required fields for a particular consumer (e.g., browser vs. cell) to keep away from over-fetching?
• What occurs if the consumer under-fetches knowledge and requires extra backend calls to retrieve lacking entities?
• How ought to parent-child relationships be dealt with? Ought to baby entities be embedded inside their mum or dad, or ought to normalization be utilized, the place mum or dad entities solely reference baby entity IDs to enhance reusability and scale back response dimension?

On this article, we discover how the X (previously Twitter) house timeline API (x.com/house) addresses these challenges, together with:

• Fetching the checklist of tweets
• Returning hierarchical or linked knowledge (e.g., tweets, customers, media)
• Sorting and paginating outcomes
• Retrieving tweet particulars
• Liking a tweet

Our focus will likely be on the API design and performance, treating the backend as a black field since its implementation is inaccessible.

Exhibiting the precise requests and responses right here is perhaps cumbersome and laborious to observe for the reason that deeply nested and repetitive objects are laborious to learn. To make it simpler to see the request/response payload construction, I’ve made my try and “sort out” the house timeline API in TypeScript. So in relation to the request/response examples I’ll use the request and response sorts as an alternative of precise JSON objects. Additionally, keep in mind that the kinds are simplified and lots of properties are omitted for brevity.

You might discover every kind in types/x.ts file or on the backside of this text within the “Appendix: Every type at one place” part.

All photos, until othewise famous, are by the creator.

Fetching the checklist of tweets for the house timeline begins with the POST request to the next endpoint:

POST https://x.com/i/api/graphql/{query-id}/HomeTimeline

Here’s a simplified request physique sort:

sort TimelineRequest = {
queryId: string; // 's6ERr1UxkxxBx4YundNsXw'
variables: {
depend: quantity; // 20
cursor?: string; // 'DAAACgGBGedb3Vx__9sKAAIZ5g4QENc99AcAAwAAIAIAAA'
seenTweetIds: string[]; // ['1867041249938530657', '1867041249938530659']
};
options: Options;
};
sort Options = {
articles_preview_enabled: boolean;
view_counts_everywhere_api_enabled: boolean;
// ...
}

Here’s a simplified response physique sort (we’ll dive deeper into the response sub-types under):

sort TimelineResponse = {
knowledge: {
house: {
home_timeline_urt: {
directions: (TimelineAddEntries | TimelineTerminateTimeline)[];
responseObjects: {
feedbackActions: TimelineAction[];
};
};
};
};
};
sort TimelineAddEntries =  TimelineCursor ;
sort TimelineItem = {
entryId: string; // 'tweet-1867041249938530657'
sortIndex: string; // '1866561576636152411'
content material: {
__typename: 'TimelineTimelineItem';
itemContent: TimelineTweet;
feedbackInfo: {
feedbackKeys: ActionKey[]; // ['-1378668161']
};
};
};
sort TimelineTweet = {
__typename: 'TimelineTweet';
tweet_results: {
end result: Tweet;
};
};
sort TimelineCursor = {
entryId: string; // 'cursor-top-1867041249938530657'
sortIndex: string; // '1866961576813152212'
content material:  'Backside';
;
};
sort ActionKey = string;

It’s fascinating to notice right here, that “getting” the information is finished through “POSTing”, which isn’t widespread for the REST-like API however it’s common for a GraphQL-like API. Additionally, the graphql a part of the URL signifies that X is utilizing the GraphQL taste for his or her API.

I’m utilizing the phrase “taste” right here as a result of the request physique itself doesn’t appear like a pure GraphQL query, the place we could describe the required response construction, itemizing all of the properties we wish to fetch:

# An instance of a pure GraphQL request construction that's *not* getting used within the X API.
{
tweets {
id
description
created_at
medias {
variety
url
# ...
}
creator {
id
title
# ...
}
# ...
}
}

The belief right here is that the house timeline API just isn’t a pure GraphQL API, however is a mixture of a number of approaches. Passing the parameters in a POST request like this appears nearer to the “practical” RPC name. However on the identical time, it looks as if the GraphQL options is perhaps used someplace on the backend behind the HomeTimeline endpoint handler/controller. A mixture like this may additionally be brought on by a legacy code or some type of ongoing migration. However once more, these are simply my speculations.

You might also discover that the identical TimelineRequest.queryId is used within the API URL in addition to within the API request physique. This queryId is most likely generated on the backend, then it will get embedded within the primary.js bundle, after which it’s used when fetching the information from the backend. It’s laborious for me to know how this queryId is used precisely since X’s backend is a black field in our case. However, once more, the hypothesis right here is perhaps that, it is perhaps wanted for some type of efficiency optimization (re-using some pre-computed question outcomes?), caching (Apollo associated?), debugging (be a part of logs by queryId?), or monitoring/tracing functions.

Additionally it is fascinating to notice, that the TimelineResponse comprises not an inventory of tweets, however relatively an inventory of directions, like “add a tweet to the timeline” (see the TimelineAddEntries sort), or “terminate the timeline” (see the TimelineTerminateTimeline sort).

The TimelineAddEntries instruction itself may additionally comprise several types of entities:

• Tweets — see the TimelineItem sort
• Cursors — see the TimelineCursor sort
• Conversations/feedback/threads — see the TimelineModule sort

sort TimelineResponse = {
knowledge: {
house: {
home_timeline_urt:  TimelineTerminateTimeline)[]; // <-- Right here
// ...
;
};
};
};
sort TimelineAddEntries =  TimelineModule)[]; // <-- Right here
;

That is fascinating from the extendability standpoint because it permits a greater diversity of what may be rendered within the house timeline with out tweaking the API an excessive amount of.

The TimelineRequest.variables.depend property units what number of tweets we wish to fetch directly (per web page). The default is 20. Nevertheless, greater than 20 tweets may be returned within the TimelineAddEntries.entries array. For instance, the array would possibly comprise 37 entries for the primary web page load, as a result of it consists of tweets (29), pinned tweets (1), promoted tweets (5), and pagination cursors (2). I am undecided why there are 29 common tweets with the requested depend of 20 although.

The TimelineRequest.variables.cursor is chargeable for the cursor-based pagination.

“Cursor pagination is most frequently used for real-time knowledge because of the frequency new information are added and since when studying knowledge you usually see the most recent outcomes first. It eliminates the opportunity of skipping gadgets and displaying the identical merchandise greater than as soon as. In cursor-based pagination, a relentless pointer (or cursor) is used to maintain monitor of the place within the knowledge set the following gadgets needs to be fetched from.” See the Offset pagination vs Cursor pagination thread for the context.

When fetching the checklist of tweets for the primary time the TimelineRequest.variables.cursor is empty, since we wish to fetch the highest tweets from the default (most likely pre-computed) checklist of customized tweets.

Nevertheless, within the response, together with the tweet knowledge, the backend additionally returns the cursor entries. Right here is the response sort hierarchy: TimelineResponse → TimelineAddEntries → TimelineCursor:

sort TimelineResponse = {
knowledge: {
homet: {
home_timeline_urt:  TimelineTerminateTimeline)[]; // <-- Right here
// ...
;
};
};
};
sort TimelineAddEntries =  TimelineCursor ;
sort TimelineCursor = {
entryId: string;
sortIndex: string;
content material:  'Backside';
;
};

Each web page comprises the checklist of tweets together with “prime” and “backside” cursors:

After the web page knowledge is loaded, we are able to go from the present web page in each instructions and fetch both the “earlier/older” tweets utilizing the “backside” cursor or the “subsequent/newer” tweets utilizing the “prime” cursor. My assumption is that fetching the “subsequent” tweets utilizing the “prime” cursor occurs in two instances: when the brand new tweets had been added whereas the consumer remains to be studying the present web page, or when the consumer begins scrolling the feed upwards (and there aren’t any cached entries or if the earlier entries had been deleted for the efficiency causes).

The X’s cursor itself would possibly appear like this: DAABCgABGemI6Mk__9sKAAIZ6MSYG9fQGwgAAwAAAAIAAA. In some API designs, the cursor could also be a Base64 encoded string that comprises the id of the final entry within the checklist, or the timestamp of the final seen entry. For instance: eyJpZCI6ICIxMjM0NTY3ODkwIn0= --> {"id": "1234567890"}, after which, this knowledge is used to question the database accordingly. Within the case of X API, it seems just like the cursor is being Base64 decoded into some customized binary sequence that may require some additional decoding to get any which means out of it (i.e. through the Protobuf message definitions). Since we do not know if it’s a .proto encoding and in addition we do not know the .proto message definition we may assume that the backend is aware of easy methods to question the following batch of tweets based mostly on the cursor string.

The TimelineResponse.variables.seenTweetIds parameter is used to tell the server about which tweets from the at the moment lively web page of the infinite scrolling the consumer has already seen. This most likely helps be certain that the server doesn’t embody duplicate tweets in subsequent pages of outcomes.

One of many challenges to be solved within the APIs like house timeline (or House Feed) is to determine easy methods to return the linked or hierarchical entities (i.e. tweet → consumer, tweet → media, media → creator, and so on):

• Ought to we solely return the checklist of tweets first after which fetch the dependent entities (like consumer particulars) in a bunch of separate queries on-demand?
• Or ought to we return all the information directly, rising the time and the scale of the primary load, however saving the time for all subsequent calls?
• Do we have to normalize the information on this case to scale back the payload dimension (i.e. when the identical consumer is an creator of many tweets and we wish to keep away from repeating the consumer knowledge over and over in every tweet entity)?
• Or ought to or not it’s a mixture of the approaches above?

Let’s see how X handles it.

Earlier within the TimelineTweet sort the Tweet sub-type was used. Let’s examine the way it seems:

export sort TimelineResponse = {
knowledge: {
house: {
home_timeline_urt:  TimelineTerminateTimeline)[]; // <-- Right here
// ...
;
};
};
};
sort TimelineAddEntries =  TimelineModule)[]; // <-- Right here
;
sort TimelineItem = {
entryId: string;
sortIndex: string;
content material: {
__typename: 'TimelineTimelineItem';
itemContent: TimelineTweet; // <-- Right here
// ...
};
};
sort TimelineTweet = {
__typename: 'TimelineTweet';
tweet_results: {
end result: Tweet; // <-- Right here
};
};
// A Tweet entity
sort Tweet = {
__typename: 'Tweet';
core: {
user_results: {
end result: Consumer; // <-- Right here (a dependent Consumer entity)
};
};
legacy: {
full_text: string;
// ...
entities: { // <-- Right here (a dependent Media entities)
media: Media[];
hashtags: Hashtag[];
urls: Url[];
user_mentions: UserMention[];
};
};
};
// A Consumer entity
sort Consumer = {
__typename: 'Consumer';
id: string; // 'VXNlcjoxNDUxM4ADSG44MTA4NDc4OTc2'
// ...
legacy: {
location: string; // 'San Francisco'
title: string; //  'John Doe'
// ...
};
};
// A Media entity
sort Media = {
// ...
source_user_id_str: string; // '1867041249938530657'  <-- Right here (the dependant consumer is being talked about by its ID)
url: string; // 'https://t.co/X78dBgtrsNU'
options: {
giant: { faces: FaceGeometry[] };
medium: { faces: FaceGeometry[] };
small: { faces: FaceGeometry[] };
orig: { faces: FaceGeometry[] };
};
sizes: {
giant: MediaSize;
medium: MediaSize;
small: MediaSize;
thumb: MediaSize;
};
video_info: VideoInfo[];
};

What’s fascinating right here is that many of the dependent knowledge like tweet → media and tweet → creator is embedded into the response on the primary name (no subsequent queries).

Additionally, the Consumer and Media connections with Tweet entities should not normalized (if two tweets have the identical creator, their knowledge will likely be repeated in every tweet object). Nevertheless it looks as if it needs to be okay, since within the scope of the house timeline for a particular consumer the tweets will likely be authored by many authors and repetitions are potential however sparse.

My assumption was that the UserTweets API (that we do not cowl right here), which is chargeable for fetching the tweets of one explicit consumer will deal with it in another way, however, apparently, it’s not the case. The UserTweets returns the checklist of tweets of the identical consumer and embeds the identical consumer knowledge over and over for every tweet. It is fascinating. Possibly the simplicity of the strategy beats some knowledge dimension overhead (perhaps consumer knowledge is taken into account fairly small in dimension). I am undecided.

One other remark in regards to the entities’ relationship is that the Media entity additionally has a hyperlink to the Consumer (the creator). Nevertheless it does it not through direct entity embedding because the Tweet entity does, however relatively it hyperlinks through the Media.source_user_id_str property.

The “feedback” (that are additionally the “tweets” by their nature) for every “tweet” within the house timeline should not fetched in any respect. To see the tweet thread the consumer should click on on the tweet to see its detailed view. The tweet thread will likely be fetched by calling the TweetDetail endpoint (extra about it within the “Tweet element web page” part under).

One other entity that every Tweet has is FeedbackActions (i.e. “Suggest much less usually” or “See fewer”). The best way the FeedbackActions are saved within the response object is totally different from the way in which the Consumer and Media objects are saved. Whereas the Consumer and Media entities are a part of the Tweet, the FeedbackActions are saved individually in TimelineItem.content material.feedbackInfo.feedbackKeys array and are linked through the ActionKey. That was a slight shock for me because it does not appear to be the case that any motion is re-usable. It seems like one motion is used for one explicit tweet solely. So it looks as if the FeedbackActions may very well be embedded into every tweet in the identical method as Media entities. However I is perhaps lacking some hidden complexity right here (like the truth that every motion can have youngsters actions).

Extra particulars in regards to the actions are within the “Tweet actions” part under.

The sorting order of the timeline entries is outlined by the backend through the sortIndex properties:

sort TimelineCursor = {
entryId: string;
sortIndex: string; // '1866961576813152212' <-- Right here
content material:  'Backside';
;
};
sort TimelineItem = {
entryId: string;
sortIndex: string; // '1866561576636152411' <-- Right here
content material: {
__typename: 'TimelineTimelineItem';
itemContent: TimelineTweet;
feedbackInfo: {
feedbackKeys: ActionKey[];
};
};
};
sort TimelineModule = {
entryId: string;
sortIndex: string; // '73343543020642838441' <-- Right here
content material: {
__typename: 'TimelineTimelineModule';
gadgets: {
entryId: string,
merchandise: TimelineTweet,
}[],
displayType: 'VerticalConversation',
};
};

The sortIndex itself would possibly look one thing like this '1867231621095096312'. It doubtless corresponds on to or is derived from a Snowflake ID.

Really many of the IDs you see within the response (tweet IDs) observe the “Snowflake ID” conference and appear like '1867231621095096312'.

If that is used to kind entities like tweets, the system leverages the inherent chronological sorting of Snowflake IDs. Tweets or objects with a better sortIndex worth (a more moderen timestamp) seem increased within the feed, whereas these with decrease values (an older timestamp) seem decrease within the feed.

Right here’s the step-by-step decoding of the Snowflake ID (in our case the sortIndex) 1867231621095096312:

• Extract the Timestamp:
• The timestamp is derived by right-shifting the Snowflake ID by 22 bits (to take away the decrease 22 bits for knowledge heart, employee ID, and sequence): 1867231621095096312 → 445182709954
• Add Twitter’s Epoch:
• Including Twitter’s customized epoch (1288834974657) to this timestamp provides the UNIX timestamp in milliseconds: 445182709954 + 1288834974657 → 1734017684611ms
• Convert to a human-readable date:
• Changing the UNIX timestamp to a UTC datetime provides: 1734017684611ms → 2024-12-12 15:34:44.611 (UTC)

So we are able to assume right here that the tweets within the house timeline are sorted chronologically.

Every tweet has an “Actions” menu.

The actions for every tweet are coming from the backend in a TimelineItem.content material.feedbackInfo.feedbackKeys array and are linked with the tweets through the ActionKey:

sort TimelineResponse = {
knowledge: {
house: {
home_timeline_urt: {
directions: (TimelineAddEntries | TimelineTerminateTimeline)[];
responseObjects: {
feedbackActions: TimelineAction[]; // <-- Right here
};
};
};
};
};
sort TimelineItem = {
entryId: string;
sortIndex: string;
content material: {
__typename: 'TimelineTimelineItem';
itemContent: TimelineTweet;
feedbackInfo: {
feedbackKeys: ActionKey[]; // ['-1378668161'] <-- Right here
};
};
};
sort TimelineAction = {
key: ActionKey; // '-609233128'
worth:  'DontLike' ;
};

It’s fascinating right here that this flat array of actions is definitely a tree (or a graph? I didn’t test), since every motion could have baby actions (see the TimelineAction.worth.childKeys array). This is sensible, for instance, when after the consumer clicks on the “Do not Like” motion, the follow-up is perhaps to indicate the “This publish isn’t related” motion, as a method of explaining why the consumer does not just like the tweet.

As soon as the consumer want to see the tweet element web page (i.e. to see the thread of feedback/tweets), the consumer clicks on the tweet and the GET request to the next endpoint is carried out:

GET https://x.com/i/api/graphql/{query-id}/TweetDetail?variables={"focalTweetId":"1867231621095096312","referrer":"house","controller_data":"DACABBSQ","rankingMode":"Relevance","includePromotedContent":true,"withCommunity":true}&options={"articles_preview_enabled":true}

I used to be curious right here why the checklist of tweets is being fetched through the POST name, however every tweet element is fetched through the GET name. Appears inconsistent. Particularly preserving in thoughts that related question parameters like query-id, options, and others this time are handed within the URL and never within the request physique. The response format can also be related and is re-using the kinds from the checklist name. I am undecided why is that. However once more, I am positive I is perhaps is perhaps lacking some background complexity right here.

Listed here are the simplified response physique sorts:

sort TweetDetailResponse = {
knowledge: {
threaded_conversation_with_injections_v2:  TimelineTerminateTimeline)[],
,
},
}
sort TimelineAddEntries =  TimelineCursor ;
sort TimelineTerminateTimeline = {
sort: 'TimelineTerminateTimeline',
path: 'High',
}
sort TimelineModule = {
entryId: string; // 'conversationthread-58668734545929871193'
sortIndex: string; // '1867231621095096312'
content material: {
__typename: 'TimelineTimelineModule';
gadgets: {
entryId: string, // 'conversationthread-1866876425669871193-tweet-1866876038930951193'
merchandise: TimelineTweet,
}[], // Feedback to the tweets are additionally tweets
displayType: 'VerticalConversation',
};
};

The response is fairly related (in its sorts) to the checklist response, so we received’t for too lengthy right here.

One fascinating nuance is that the “feedback” (or conversations) of every tweet are literally different tweets (see the TimelineModule sort). So the tweet thread seems similar to the house timeline feed by displaying the checklist of TimelineTweet entries. This seems elegant. A very good instance of a common and re-usable strategy to the API design.

When a consumer likes the tweet, the POST request to the next endpoint is being carried out:

POST https://x.com/i/api/graphql/{query-id}/FavoriteTweet

Right here is the request physique sorts:

sort FavoriteTweetRequest = {
variables: {
tweet_id: string; // '1867041249938530657'
};
queryId: string; // 'lI07N61twFgted2EgXILM7A'
};

Right here is the response physique sorts:

sort FavoriteTweetResponse = {
knowledge: {
favorite_tweet: 'Performed',
}
}

Seems simple and in addition resembles the RPC-like strategy to the API design.

We now have touched on some fundamental elements of the house timeline API design by taking a look at X’s API instance. I made some assumptions alongside the way in which to the very best of my data. I consider some issues I might need interpreted incorrectly and I might need missed some advanced nuances. However even with that in thoughts, I hope you bought some helpful insights from this high-level overview, one thing that you could possibly apply in your subsequent API Design session.

Initially, I had a plan to undergo related top-tech web sites to get some insights from Fb, Reddit, YouTube, and others and to gather battle-tested greatest practices and options. I’m undecided if I’ll discover the time to try this. Will see. Nevertheless it may very well be an fascinating train.

For the reference, I’m including every kind in a single go right here. You might also discover every kind in types/x.ts file.

/**
* This file comprises the simplified sorts for X's (Twitter's) house timeline API.
*
* These sorts are created for exploratory functions, to see the present implementation
* of the X's API, to see how they fetch House Feed, how they do a pagination and sorting,
* and the way they cross the hierarchical entities (posts, media, consumer data, and so on).
*
* Many properties and kinds are omitted for simplicity.
*/
// POST https://x.com/i/api/graphql/{query-id}/HomeTimeline
export sort TimelineRequest = {
queryId: string; // 's6ERr1UxkxxBx4YundNsXw'
variables: {
depend: quantity; // 20
cursor?: string; // 'DAAACgGBGedb3Vx__9sKAAIZ5g4QENc99AcAAwAAIAIAAA'
seenTweetIds: string[]; // ['1867041249938530657', '1867041249938530658']
};
options: Options;
};
// POST https://x.com/i/api/graphql/{query-id}/HomeTimeline
export sort TimelineResponse = {
knowledge: {
house: {
home_timeline_urt: {
directions: (TimelineAddEntries | TimelineTerminateTimeline)[];
responseObjects: {
feedbackActions: TimelineAction[];
};
};
};
};
};
// POST https://x.com/i/api/graphql/{query-id}/FavoriteTweet
export sort FavoriteTweetRequest = {
variables: {
tweet_id: string; // '1867041249938530657'
};
queryId: string; // 'lI07N6OtwFgted2EgXILM7A'
};
// POST https://x.com/i/api/graphql/{query-id}/FavoriteTweet
export sort FavoriteTweetResponse = {
knowledge: {
favorite_tweet: 'Performed',
}
}
// GET https://x.com/i/api/graphql/{query-id}/TweetDetail?variables={"focalTweetId":"1867041249938530657","referrer":"house","controller_data":"DACABBSQ","rankingMode":"Relevance","includePromotedContent":true,"withCommunity":true}&options={"articles_preview_enabled":true}
export sort TweetDetailResponse = {
knowledge: {
threaded_conversation_with_injections_v2:  TimelineTerminateTimeline)[],
,
},
}
sort Options = {
articles_preview_enabled: boolean;
view_counts_everywhere_api_enabled: boolean;
// ...
}
sort TimelineAction = {
key: ActionKey; // '-609233128'
worth:  'DontLike' ;
};
sort TimelineAddEntries =  TimelineCursor ;
sort TimelineTerminateTimeline = {
sort: 'TimelineTerminateTimeline',
path: 'High',
}
sort TimelineCursor = {
entryId: string; // 'cursor-top-1867041249938530657'
sortIndex: string; // '1867231621095096312'
content material:  'Backside';
;
};
sort TimelineItem = {
entryId: string; // 'tweet-1867041249938530657'
sortIndex: string; // '1867231621095096312'
content material: {
__typename: 'TimelineTimelineItem';
itemContent: TimelineTweet;
feedbackInfo: {
feedbackKeys: ActionKey[]; // ['-1378668161']
};
};
};
sort TimelineModule = {
entryId: string; // 'conversationthread-1867041249938530657'
sortIndex: string; // '1867231621095096312'
content material: {
__typename: 'TimelineTimelineModule';
gadgets: {
entryId: string, // 'conversationthread-1867041249938530657-tweet-1867041249938530657'
merchandise: TimelineTweet,
}[], // Feedback to the tweets are additionally tweets
displayType: 'VerticalConversation',
};
};
sort TimelineTweet = {
__typename: 'TimelineTweet';
tweet_results: {
end result: Tweet;
};
};
sort Tweet = {
__typename: 'Tweet';
core: {
user_results: {
end result: Consumer;
};
};
views: {
depend: string; // '13763'
};
legacy: {
bookmark_count: quantity; // 358
created_at: string; // 'Tue Dec 10 17:41:28 +0000 2024'
conversation_id_str: string; // '1867041249938530657'
display_text_range: quantity[]; // [0, 58]
favorite_count: quantity; // 151
full_text: string; //  "How I would promote my startup, if I had 0 followers (Half 1)"
lang: string; // 'en'
quote_count: quantity;
reply_count: quantity;
retweet_count: quantity;
user_id_str: string; // '1867041249938530657'
id_str: string; // '1867041249938530657'
entities: {
media: Media[];
hashtags: Hashtag[];
urls: Url[];
user_mentions: UserMention[];
};
};
};
sort Consumer = {
__typename: 'Consumer';
id: string; // 'VXNlcjoxNDUxM4ADSG44MTA4NDc4OTc2'
rest_id: string; // '1867041249938530657'
is_blue_verified: boolean;
profile_image_shape: 'Circle'; // ...
legacy: {
following: boolean;
created_at: string; // 'Thu Oct 21 09:30:37 +0000 2021'
description: string; // 'I assist startup founders double their MRR with outside-the-box advertising cheat sheets'
favourites_count: quantity; // 22195
followers_count: quantity; // 25658
friends_count: quantity;
location: string; // 'San Francisco'
media_count: quantity;
title: string; //  'John Doe'
profile_banner_url: string; // 'https://pbs.twimg.com/profile_banners/4863509452891265813/4863509'
profile_image_url_https: string; // 'https://pbs.twimg.com/profile_images/4863509452891265813/4863509_normal.jpg'
screen_name: string; // 'johndoe'
url: string; // 'https://t.co/dgTEddFGDd'
verified: boolean;
};
};
sort Media = {
display_url: string; // 'pic.x.com/X7823zS3sNU'
expanded_url: string; // 'https://x.com/johndoe/standing/1867041249938530657/video/1'
ext_alt_text: string; // 'Picture of two bridges.'
id_str: string; // '1867041249938530657'
indices: quantity[]; // [93, 116]
media_key: string; // '13_2866509231399826944'
media_url_https: string; // 'https://pbs.twimg.com/profile_images/1867041249938530657/4863509_normal.jpg'
source_status_id_str: string; // '1867041249938530657'
source_user_id_str: string; // '1867041249938530657'
sort: string; // 'video'
url: string; // 'https://t.co/X78dBgtrsNU'
options: {
giant: { faces: FaceGeometry[] };
medium: { faces: FaceGeometry[] };
small: { faces: FaceGeometry[] };
orig: { faces: FaceGeometry[] };
};
sizes: {
giant: MediaSize;
medium: MediaSize;
small: MediaSize;
thumb: MediaSize;
};
video_info: VideoInfo[];
};
sort UserMention = {
id_str: string; // '98008038'
title: string; // 'Yann LeCun'
screen_name: string; // 'ylecun'
indices: quantity[]; // [115, 122]
};
sort Hashtag = {
indices: quantity[]; // [257, 263]
textual content: string;
};
sort Url = {
display_url: string; // 'google.com'
expanded_url: string; // 'http://google.com'
url: string; // 'https://t.co/nZh3aF0Aw6'
indices: quantity[]; // [102, 125]
};
sort VideoInfo = {
aspect_ratio: quantity[]; // [427, 240]
duration_millis: quantity; // 20000
variants:  ...
url: string; // 'https://video.twimg.com/amplify_video/18665094345456w6944/pl/-ItQau_LRWedR-W7.m3u8?tag=14'
;
};
sort FaceGeometry = { x: quantity; y: quantity; h: quantity; w: quantity };
sort MediaSize =  'crop' ;
sort ActionKey = string;