A more in-depth 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, equivalent to REST vs RPC vs GraphQL, or hybrid fashions, to find out the very best match for a selected activity or challenge. 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 shopper (e.g., browser vs. cell) to keep away from over-fetching?
- What occurs if the shopper under-fetches information and requires extra backend calls to retrieve lacking entities?
- How ought to parent-child relationships be dealt with? Ought to little one entities be embedded inside their father or mother, or ought to normalization be utilized, the place father or mother entities solely reference little one entity IDs to enhance reusability and cut 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 record 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 probably 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 could be cumbersome and exhausting to comply with because the deeply nested and repetitive objects are exhausting to learn. To make it simpler to see the request/response payload construction, I’ve made my try to “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 a substitute of precise JSON objects. Additionally, keep in mind that the kinds are simplified and lots of properties are omitted for brevity.
Chances are you’ll discover all sorts in types/x.ts file or on the backside of this text within the “Appendix: Every type at one place” part.
All photographs, until othewise famous, are by the writer.
Fetching the record 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 beneath):
sort TimelineResponse = {
information: {
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: {
consequence: Tweet;
};
};
sort TimelineCursor = {
entryId: string; // 'cursor-top-1867041249938530657'
sortIndex: string; // '1866961576813152212'
content material: 'Backside';
;
};
sort ActionKey = string;
It’s attention-grabbing to notice right here, that “getting” the information 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 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 {
sort
url
# ...
}
writer {
id
title
# ...
}
# ...
}
}
The idea right here is that the house timeline API shouldn’t 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 “purposeful” RPC name. However on the identical time, it looks like the GraphQL options could be used someplace on the backend behind the HomeTimeline endpoint handler/controller. A mixture like this may additionally be attributable to a legacy code or some kind 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 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 exhausting for me to grasp how this queryId is used precisely since X’s backend is a black field in our case. However, once more, the hypothesis right here could be that, it could be wanted for some kind of efficiency optimization (re-using some pre-computed question outcomes?), caching (Apollo associated?), debugging (be part of logs by queryId?), or monitoring/tracing functions.
It is usually attention-grabbing to notice, that the TimelineResponse incorporates not a listing of tweets, however quite a listing 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 various kinds of entities:
- Tweets — see the
TimelineItemsort - Cursors — see the
TimelineCursorsort - Conversations/feedback/threads — see the
TimelineModulesort
sort TimelineResponse = {
information: {
house: {
home_timeline_urt: TimelineTerminateTimeline)[]; // <-- Right here
// ...
;
};
};
};sort TimelineAddEntries = TimelineModule)[]; // <-- Right here
;
That is attention-grabbing from the extendability standpoint because it permits a greater variety 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 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 unsure 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 information because of the 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 record of tweets for the primary time the TimelineRequest.variables.cursor is empty, since we wish to fetch the highest tweets from the default (likely pre-computed) record of customized tweets.
Nevertheless, within the response, together with the tweet information, the backend additionally returns the cursor entries. Right here is the response sort hierarchy: TimelineResponse → TimelineAddEntries → TimelineCursor:
sort TimelineResponse = {
information: {
homet: {
home_timeline_urt: TimelineTerminateTimeline)[]; // <-- Right here
// ...
;
};
};
};sort TimelineAddEntries = TimelineModule)[]; // <-- Right here (tweets + cursors)
;
sort TimelineCursor = {
entryId: string;
sortIndex: string;
content material: 'Backside';
;
};
Each web page incorporates the record of tweets together with “high” and “backside” cursors:
After the web page information is loaded, we will 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 “high” cursor. My assumption is that fetching the “subsequent” tweets utilizing the “high” cursor occurs in two instances: when the brand new tweets had been added whereas the person remains to be studying the present web page, or when the person begins scrolling the feed upwards (and there are not any cached entries or if the earlier entries had 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 incorporates the id of the final entry within the record, 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 which 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 could assume that the backend is aware of the way 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 the moment energetic web page of the infinite scrolling the shopper has already seen. This likely helps make sure that the server doesn’t embrace 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 the way to return the linked or hierarchical entities (i.e. tweet → person, tweet → media, media → writer, and so forth):
- Ought to we solely return the record 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 information directly, rising the time and the dimensions of the primary load, however saving the time for all subsequent calls?
- Do we have to normalize the information on this case to cut back the payload dimension (i.e. when the identical person is an writer of many tweets and we wish to keep away from repeating the person information again and again 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 appears to be like:
export sort TimelineResponse = {
information: {
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: {
consequence: Tweet; // <-- Right here
};
};
// A Tweet entity
sort Tweet = {
__typename: 'Tweet';
core: {
user_results: {
consequence: 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
sort Person = {
__typename: 'Person';
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 person is being talked about by its ID)
url: string; // 'https://t.co/X78dBgtrsNU'
options: {
massive: { faces: FaceGeometry[] };
medium: { faces: FaceGeometry[] };
small: { faces: FaceGeometry[] };
orig: { faces: FaceGeometry[] };
};
sizes: {
massive: 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 should not normalized (if two tweets have the identical writer, their information will probably be repeated in every tweet object). However it looks like it must be okay, since within the scope of the house timeline for a selected person the tweets will probably be authored by many authors and repetitions are doable 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 person will deal with it in a different way, however, apparently, it isn’t the case. The UserTweets returns the record of tweets of the identical person and embeds the identical person information again and again for every tweet. It is attention-grabbing. Perhaps the simplicity of the method beats some information dimension overhead (perhaps person information is taken into account fairly small in dimension). I am unsure.
One other statement in regards to the entities’ relationship is that the Media entity additionally has a hyperlink to the Person (the writer). However it does it not by way of direct entity embedding because the Tweet entity does, however quite 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 house timeline should not 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 probably be fetched by calling the TweetDetail endpoint (extra about it within the “Tweet element web page” part beneath).
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 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 does not appear to be the case that any motion is re-usable. It appears to be like like one motion is used for one explicit tweet solely. So it looks like the FeedbackActions may very well be embedded into every tweet in the identical means as Media entities. However I could 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 beneath.
The sorting order of the timeline entries is outlined by the backend by way of 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 may 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) 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 a better sortIndex worth (a more moderen timestamp) seem larger 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 middle, 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 will 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 by way of the ActionKey:
sort TimelineResponse = {
information: {
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 attention-grabbing right here that this flat array of actions is definitely a tree (or a graph? I didn’t verify), since every motion could have little one 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 could be to point out the “This put up isn’t related” motion, as a means of explaining why the person does not just like the tweet.
As soon as the person want 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":"house","controller_data":"DACABBSQ","rankingMode":"Relevance","includePromotedContent":true,"withCommunity":true}&options={"articles_preview_enabled":true}
I used to be curious right here why the record 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 be related and is re-using the kinds from the record name. I am unsure why is that. However once more, I am certain I could be could be lacking some background complexity right here.
Listed here are the simplified response physique sorts:
sort TweetDetailResponse = {
information: {
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 record response, so we gained’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 sort). So the tweet thread appears to be like similar to the house timeline feed by exhibiting the record 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 sorts:
sort FavoriteTweetRequest = {
variables: {
tweet_id: string; // '1867041249938530657'
};
queryId: string; // 'lI07N61twFgted2EgXILM7A'
};
Right here is the response physique sorts:
sort FavoriteTweetResponse = {
information: {
favorite_tweet: 'Executed',
}
}
Appears to be like simple and likewise resembles the RPC-like method to the API design.
We’ve 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 imagine some issues I might need interpreted incorrectly and I might need missed some complicated nuances. However even with that in thoughts, I hope you bought some helpful insights from this high-level overview, one thing that you possibly can 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 unsure if I’ll discover the time to do this. Will see. However 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 types/x.ts file.
/**
* This file incorporates 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 move the hierarchical entities (posts, media, person data, and so forth).
*
* 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 = {
information: {
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 = {
information: {
favorite_tweet: 'Executed',
}
}
// 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 = {
information: {
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: {
consequence: Tweet;
};
};
sort Tweet = {
__typename: 'Tweet';
core: {
user_results: {
consequence: Person;
};
};
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 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 and marketing 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: {
massive: { faces: FaceGeometry[] };
medium: { faces: FaceGeometry[] };
small: { faces: FaceGeometry[] };
orig: { faces: FaceGeometry[] };
};
sizes: {
massive: 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: 'video/mp4' ;
};
sort FaceGeometry = { x: quantity; y: quantity; h: quantity; w: quantity };
sort MediaSize = 'crop' ;
sort ActionKey = string;
