How X (Twitter) Designed Its House Timeline API: Classes to Be taught | by Oleksii Trekhleb | Dec, 2024

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

When designing a system’s API, software program engineers usually consider numerous approaches, comparable to REST vs RPC vs GraphQL, or hybrid fashions, to find out the most effective match for a selected activity or undertaking. These approaches outline how information flows between the backend and frontend, in addition to the construction of the response information:

• Ought to all information 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 selected consumer (e.g., browser vs. cell) to keep away from over-fetching?
• What occurs if the consumer under-fetches information and requires extra backend calls to retrieve lacking entities?
• How ought to parent-child relationships be dealt with? Ought to youngster entities be embedded inside their mother or father, or ought to normalization be utilized, the place mother or father entities solely reference youngster entity IDs to enhance reusability and scale back response measurement?

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

• Fetching the checklist of tweets
• Returning hierarchical or linked information (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.

Displaying the precise requests and responses right here is likely to be cumbersome and onerous to comply with for the reason that deeply nested and repetitive objects are onerous to learn. To make it simpler to see the request/response payload construction, I’ve made my try to “kind out” the house timeline API in TypeScript. So with regards to the request/response examples I’ll use the request and response varieties as a substitute of precise JSON objects. Additionally, do not forget that the kinds are simplified and plenty of properties are omitted for brevity.

Chances are you’ll discover all sorts in varieties/x.ts file or on the backside of this text within the “Appendix: All kinds at one place” part.

All photos, except othewise famous, are by the writer.

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 kind:

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

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

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

It’s attention-grabbing to notice right here, that “getting” the info is completed by way of “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 to be a pure GraphQL question, 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 {
type
url
# ...
}
writer {
id
title
# ...
}
# ...
}
}

The belief right here is that the house timeline API will not be 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 “useful” RPC name. However on the identical time, it looks as if the GraphQL options is likely to be used someplace on the backend behind the HomeTimeline endpoint handler/controller. A combination like this may also be attributable to a legacy code or some type of ongoing migration. However once more, these are simply my speculations.

You may additionally 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 principal.js bundle, after which it’s used when fetching the info from the backend. It’s onerous 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 likely to be that, it is likely to be 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.

It is usually attention-grabbing to notice, that the TimelineResponse accommodates not an inventory of tweets, however fairly an inventory of directions, like “add a tweet to the timeline” (see the TimelineAddEntries kind), or “terminate the timeline” (see the TimelineTerminateTimeline kind).

The TimelineAddEntries instruction itself can also comprise various kinds of entities:

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

kind TimelineResponse = {
information: {
residence: {
home_timeline_urt:  TimelineTerminateTimeline)[]; // <-- Right here
// ...
;
};
};
};
kind TimelineAddEntries =  TimelineModule)[]; // <-- Right here
;

That is attention-grabbing from the extendability standpoint because it permits a greater variety of what will be rendered within the residence timeline with out tweaking the API an excessive amount of.

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

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

“Cursor pagination is most frequently used for real-time information as a result of frequency new data are added and since when studying information you usually see the most recent outcomes first. It eliminates the potential for 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 observe of the place within the information set the subsequent gadgets must 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 personalised tweets.

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

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

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

After the web page information 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 circumstances: when the brand new tweets have been added whereas the person remains to be studying the present web page, or when the person begins scrolling the feed upwards (and there aren’t any cached entries or if the earlier entries have been deleted for the efficiency causes).

The X’s cursor itself may appear to be this: DAABCgABGemI6Mk__9sKAAIZ6MSYG9fQGwgAAwAAAAIAAA. In some API designs, the cursor could also be a Base64 encoded string that accommodates 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 information is used to question the database accordingly. Within the case of X API, it appears to be like just like the cursor is being Base64 decoded into some customized binary sequence that may require some additional decoding to get any that means out of it (i.e. by way of the Protobuf message definitions). Since we do not know if it’s a .proto encoding and likewise we do not know the .proto message definition we may assume that the backend is aware of find out how to question the subsequent batch of tweets primarily based on the cursor string.

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

One of many challenges to be solved within the APIs like residence timeline (or House Feed) is to determine find out how to return the linked or hierarchical entities (i.e. tweet → person, tweet → media, media → writer, and many others):

• Ought to we solely return the checklist of tweets first after which fetch the dependent entities (like person particulars) in a bunch of separate queries on-demand?
• Or ought to we return all the info 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 info on this case to scale back the payload measurement (i.e. when the identical person is an writer of many tweets and we wish to keep away from repeating the person information over and over in every tweet entity)?
• Or ought to it’s a mixture of the approaches above?

Let’s see how X handles it.

Earlier within the TimelineTweet kind the Tweet sub-type was used. Let’s examine the way it appears to be like:

export kind TimelineResponse = {
information: {
residence: {
home_timeline_urt:  TimelineTerminateTimeline)[]; // <-- Right here
// ...
;
};
};
};
kind TimelineAddEntries =  TimelineModule)[]; // <-- Right here
;
kind TimelineItem = {
entryId: string;
sortIndex: string;
content material: {
__typename: 'TimelineTimelineItem';
itemContent: TimelineTweet; // <-- Right here
// ...
};
};
kind TimelineTweet = {
__typename: 'TimelineTweet';
tweet_results: {
outcome: Tweet; // <-- Right here
};
};
// A Tweet entity
kind Tweet = {
__typename: 'Tweet';
core: {
user_results: {
outcome: Person; // <-- Right here (a dependent Person entity)
};
};
legacy: {
full_text: string;
// ...
entities: { // <-- Right here (a dependent Media entities)
media: Media[];
hashtags: Hashtag[];
urls: Url[];
user_mentions: UserMention[];
};
};
};
// A Person entity
kind Person = {
__typename: 'Person';
id: string; // 'VXNlcjoxNDUxM4ADSG44MTA4NDc4OTc2'
// ...
legacy: {
location: string; // 'San Francisco'
title: string; //  'John Doe'
// ...
};
};
// A Media entity
kind Media = {
// ...
source_user_id_str: string; // '1867041249938530657'  <-- Right here (the dependant person 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 attention-grabbing right here is that many of the dependent information like tweet → media and tweet → writer is embedded into the response on the primary name (no subsequent queries).

Additionally, the Person and Media connections with Tweet entities will not be normalized (if two tweets have the identical writer, their information will likely be repeated in every tweet object). Nevertheless it looks as if it must be okay, since within the scope of the house timeline for a selected person the tweets will likely be authored by many authors and repetitions are attainable however sparse.

My assumption was that the UserTweets API (that we do not cowl right here), which is answerable for fetching the tweets of one specific person will deal with it in another way, however, apparently, it’s not the case. The UserTweets returns the checklist of tweets of the identical person and embeds the identical person information over and over for every tweet. It is attention-grabbing. Perhaps the simplicity of the method beats some information measurement overhead (perhaps person information is taken into account fairly small in measurement). I am undecided.

One other remark in regards to the entities’ relationship is that the Media entity additionally has a hyperlink to the Person (the writer). Nevertheless it does it not by way of direct entity embedding because the Tweet entity does, however fairly it hyperlinks by way of the Media.source_user_id_str property.

The “feedback” (that are additionally the “tweets” by their nature) for every “tweet” within the residence timeline will not be fetched in any respect. To see the tweet thread the person 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 way in which the FeedbackActions are saved within the response object is completely different from the way in which the Person and Media objects are saved. Whereas the Person and Media entities are a part of the Tweet, the FeedbackActions are saved individually in TimelineItem.content material.feedbackInfo.feedbackKeys array and are linked by way of the ActionKey. That was a slight shock for me because it would not appear to be the case that any motion is re-usable. It appears to be like like one motion is used for one specific tweet solely. So it looks as if the FeedbackActions may very well be embedded into every tweet in the identical means as Media entities. However I is likely to be 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 by way of the sortIndex properties:

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

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

Really many of the IDs you see within the response (tweet IDs) comply with the “Snowflake ID” conference and appear to be '1867231621095096312'.

If that is used to type entities like tweets, the system leverages the inherent chronological sorting of Snowflake IDs. Tweets or objects with the next sortIndex worth (a newer timestamp) seem greater 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 information heart, employee ID, and sequence): 1867231621095096312 → 445182709954
• Add Twitter’s Epoch:
• Including Twitter’s customized epoch (1288834974657) to this timestamp offers the UNIX timestamp in milliseconds: 445182709954 + 1288834974657 → 1734017684611ms
• Convert to a human-readable date:
• Changing the UNIX timestamp to a UTC datetime offers: 1734017684611ms → 2024-12-12 15:34:44.611 (UTC)

So we are able to assume right here that the tweets within the residence 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 by way of the ActionKey:

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

It’s attention-grabbing right here that this flat array of actions is definitely a tree (or a graph? I didn’t test), since every motion could have youngster actions (see the TimelineAction.worth.childKeys array). This is sensible, for instance, when after the person clicks on the “Do not Like” motion, the follow-up is likely to be to indicate the “This put up isn’t related” motion, as a means of explaining why the person would not just like the tweet.

As soon as the person wish to see the tweet element web page (i.e. to see the thread of feedback/tweets), the person 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":"residence","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 by way of the POST name, however every tweet element is fetched by way of the GET name. Appears inconsistent. Particularly protecting 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 certain I is likely to be is likely to be lacking some background complexity right here.

Listed below are the simplified response physique varieties:

kind TweetDetailResponse = {
information: {
threaded_conversation_with_injections_v2:  TimelineTerminateTimeline)[],
,
},
}
kind TimelineAddEntries =  TimelineModule)[];
;
kind TimelineTerminateTimeline = {
kind: 'TimelineTerminateTimeline',
course: 'High',
}
kind 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 varieties) to the checklist response, so we received’t for too lengthy right here.

One attention-grabbing nuance is that the “feedback” (or conversations) of every tweet are literally different tweets (see the TimelineModule kind). So the tweet thread appears to be like similar to the house timeline feed by displaying the checklist of TimelineTweet entries. This appears to be like elegant. A great instance of a common and re-usable method to the API design.

When a person 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 varieties:

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

Right here is the response physique varieties:

kind FavoriteTweetResponse = {
information: {
favorite_tweet: 'Carried out',
}
}

Seems easy and likewise resembles the RPC-like method to the API design.

We now have touched on some primary components of the house timeline API design by X’s API instance. I made some assumptions alongside the way in which to the most effective of my data. I imagine some issues I may need interpreted incorrectly and I may 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 finest practices and options. I’m undecided if I’ll discover the time to do this. Will see. Nevertheless it may very well be an attention-grabbing train.

For the reference, I’m including all sorts in a single go right here. You may additionally discover all sorts in varieties/x.ts file.

/**
* This file accommodates the simplified varieties for X's (Twitter's) residence timeline API.
*
* These varieties 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 move the hierarchical entities (posts, media, person information, and many others).
*
* Many properties and kinds are omitted for simplicity.
*/
// POST https://x.com/i/api/graphql/{query-id}/HomeTimeline
export kind TimelineRequest = {
queryId: string; // 's6ERr1UxkxxBx4YundNsXw'
variables: {
rely: quantity; // 20
cursor?: string; // 'DAAACgGBGedb3Vx__9sKAAIZ5g4QENc99AcAAwAAIAIAAA'
seenTweetIds: string[]; // ['1867041249938530657', '1867041249938530658']
};
options: Options;
};
// POST https://x.com/i/api/graphql/{query-id}/HomeTimeline
export kind TimelineResponse = {
information: {
residence: {
home_timeline_urt: {
directions: (TimelineAddEntries | TimelineTerminateTimeline)[];
responseObjects: {
feedbackActions: TimelineAction[];
};
};
};
};
};
// POST https://x.com/i/api/graphql/{query-id}/FavoriteTweet
export kind FavoriteTweetRequest = {
variables: {
tweet_id: string; // '1867041249938530657'
};
queryId: string; // 'lI07N6OtwFgted2EgXILM7A'
};
// POST https://x.com/i/api/graphql/{query-id}/FavoriteTweet
export kind FavoriteTweetResponse = {
information: {
favorite_tweet: 'Carried out',
}
}
// GET https://x.com/i/api/graphql/{query-id}/TweetDetail?variables={"focalTweetId":"1867041249938530657","referrer":"residence","controller_data":"DACABBSQ","rankingMode":"Relevance","includePromotedContent":true,"withCommunity":true}&options={"articles_preview_enabled":true}
export kind TweetDetailResponse = {
information: {
threaded_conversation_with_injections_v2:  TimelineTerminateTimeline)[],
,
},
}
kind Options = {
articles_preview_enabled: boolean;
view_counts_everywhere_api_enabled: boolean;
// ...
}
kind TimelineAction = {
key: ActionKey; // '-609233128'
worth:  'DontLike' ;
};
kind TimelineAddEntries =  TimelineModule)[];
;
kind TimelineTerminateTimeline = {
kind: 'TimelineTerminateTimeline',
course: 'High',
}
kind TimelineCursor = {
entryId: string; // 'cursor-top-1867041249938530657'
sortIndex: string; // '1867231621095096312'
content material:  'Backside';
;
};
kind TimelineItem = {
entryId: string; // 'tweet-1867041249938530657'
sortIndex: string; // '1867231621095096312'
content material: {
__typename: 'TimelineTimelineItem';
itemContent: TimelineTweet;
feedbackInfo: {
feedbackKeys: ActionKey[]; // ['-1378668161']
};
};
};
kind 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',
};
};
kind TimelineTweet = {
__typename: 'TimelineTweet';
tweet_results: {
outcome: Tweet;
};
};
kind Tweet = {
__typename: 'Tweet';
core: {
user_results: {
outcome: Person;
};
};
views: {
rely: 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 might 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[];
};
};
};
kind Person = {
__typename: 'Person';
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;
};
};
kind 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'
kind: 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[];
};
kind UserMention = {
id_str: string; // '98008038'
title: string; // 'Yann LeCun'
screen_name: string; // 'ylecun'
indices: quantity[]; // [115, 122]
};
kind Hashtag = {
indices: quantity[]; // [257, 263]
textual content: string;
};
kind Url = {
display_url: string; // 'google.com'
expanded_url: string; // 'http://google.com'
url: string; // 'https://t.co/nZh3aF0Aw6'
indices: quantity[]; // [102, 125]
};
kind 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'
;
};
kind FaceGeometry = { x: quantity; y: quantity; h: quantity; w: quantity };
kind MediaSize =  'crop' ;
kind ActionKey = string;