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, akin to REST vs RPC vs GraphQL, or hybrid fashions, to find out the most effective match for a particular job 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 particular 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 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) residence timeline API (x.com/residence) addresses these challenges, together with:
- Fetching the listing 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 may be cumbersome and laborious to comply with because the 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 terms of the request/response examples I’ll use the request and response varieties as a substitute of precise JSON objects. Additionally, keep in mind that the kinds are simplified and plenty of properties are omitted for brevity.
Chances are you’ll discover every type in varieties/x.ts file or on the backside of this text within the “Appendix: Every type at one place” part.
All photos, except othewise famous, are by the writer.
Fetching the listing 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: {
rely: 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: {
residence: {
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: {
outcome: 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 info is finished through “POSTing”, which isn’t frequent for the REST-like API however it is not uncommon 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 might 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
identify
# ...
}
# ...
}
}
The belief 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 “useful” RPC name. However on the similar time, it looks as if the GraphQL options may be used someplace on the backend behind the HomeTimeline endpoint handler/controller. A mixture like this may also 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 foremost.js bundle, after which it’s used when fetching the info 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 may be that, it may 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.
Additionally it is fascinating to notice, that the TimelineResponse accommodates not an inventory of tweets, however reasonably 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 include several types of entities:
- Tweets — see the
TimelineItemsort - Cursors — see the
TimelineCursorsort - Conversations/feedback/threads — see the
TimelineModulesort
sort TimelineResponse = {
information: {
residence: {
home_timeline_urt: TimelineTerminateTimeline)[]; // <-- Right here
// ...
;
};
};
};sort TimelineAddEntries = TimelineCursor ;
That is fascinating from the extendability viewpoint because it permits a greater variety of what may 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 may be returned within the TimelineAddEntries.entries array. For instance, the array would possibly include 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 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 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 observe of the place within the information set the following gadgets must be fetched from.” See the Offset pagination vs Cursor pagination thread for the context.
When fetching the listing 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) listing of personalised 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 = TimelineCursor ;
sort TimelineCursor = {
entryId: string;
sortIndex: string;
content material: 'Backside';
;
};
Each web page accommodates the listing of tweets together with “prime” 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 “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 consumer continues to be studying the present web page, or when the consumer begins scrolling the feed upwards (and there are not any cached entries or if the earlier entries have been deleted for the efficiency causes).
The X’s cursor itself would possibly 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 listing, 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 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 how you can question the following 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 presently lively web page of the infinite scrolling the shopper has already seen. This likely helps be 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 Residence Feed) is to determine how you can return the linked or hierarchical entities (i.e. tweet → consumer, tweet → media, media → writer, and so on):
- Ought to we solely return the listing 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 info 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 info on this case to cut back the payload dimension (i.e. when the identical consumer is an writer of many tweets and we wish to keep away from repeating the consumer information time and again 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 sort the Tweet sub-type was used. Let’s examine the way it appears:
export sort TimelineResponse = {
information: {
residence: {
home_timeline_urt: TimelineTerminateTimeline)[]; // <-- Right here
// ...
;
};
};
};sort TimelineAddEntries = TimelineCursor ;
sort TimelineItem = {
entryId: string;
sortIndex: string;
content material: {
__typename: 'TimelineTimelineItem';
itemContent: TimelineTweet; // <-- Right here
// ...
};
};
sort TimelineTweet = {
__typename: 'TimelineTweet';
tweet_results: {
outcome: Tweet; // <-- Right here
};
};
// A Tweet entity
sort 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
sort Person = {
__typename: 'Person';
id: string; // 'VXNlcjoxNDUxM4ADSG44MTA4NDc4OTc2'
// ...
legacy: {
location: string; // 'San Francisco'
identify: 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 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). However it looks as if it must 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 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 specific consumer will deal with it otherwise, however, apparently, it isn’t the case. The UserTweets returns the listing of tweets of the identical consumer and embeds the identical consumer information time and again for every tweet. It is fascinating. Perhaps the simplicity of the method beats some information dimension overhead (possibly consumer information is taken into account fairly small in dimension). I am undecided.
One other statement concerning the entities’ relationship is that the Media entity additionally has a hyperlink to the Person (the writer). However it does it not through direct entity embedding because the Tweet entity does, however reasonably 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 residence timeline will not be 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 beneath).
One other entity that every Tweet has is FeedbackActions (i.e. “Advocate much less usually” or “See fewer”). The best way the FeedbackActions are saved within the response object is totally different from the best way 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 through 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 like one motion is used for one specific tweet solely. So it looks as if the FeedbackActions could possibly be embedded into every tweet in the identical method as Media entities. However I may be lacking some hidden complexity right here (like the truth that every motion can have youngsters actions).
Extra particulars concerning the actions are within the “Tweet actions” part beneath.
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) comply with the “Snowflake ID” conference and appear to be
'1867231621095096312'.
If that is used to kind entities like tweets, the system leverages the inherent chronological sorting of Snowflake IDs. Tweets or objects with the next 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 information 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 will 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 through the ActionKey:
sort TimelineResponse = {
information: {
residence: {
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: ...
affirmation: string; // 'Thanks. You’ll see fewer posts like this.'
childKeys: ActionKey[]; // ['1192182653', '-1427553257'], i.e. NotInterested -> SeeFewer
feedbackUrl: string; // '/2/timeline/suggestions.json?feedback_type=NotRelevant&action_metadata=SRwW6oXZadPHiOczBBaAwPanEwEpercent3D'
hasUndoAction: boolean;
icon: string; // 'Frown'
;
};
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 might 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 may be to point out the “This publish isn’t related” motion, as a method of explaining why the consumer would not just like the tweet.
As soon as the consumer wish 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":"residence","controller_data":"DACABBSQ","rankingMode":"Relevance","includePromotedContent":true,"withCommunity":true}&options={"articles_preview_enabled":true}
I used to be curious right here why the listing 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 comparable 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 comparable and is re-using the kinds from the listing name. I am undecided why is that. However once more, I am certain I may be may be lacking some background complexity right here.
Listed here are the simplified response physique varieties:
sort TweetDetailResponse = {
information: {
threaded_conversation_with_injections_v2: TimelineTerminateTimeline)[],
,
},
}sort TimelineAddEntries = TimelineCursor ;
sort TimelineTerminateTimeline = {
sort: 'TimelineTerminateTimeline',
course: '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 comparable (in its varieties) to the listing response, so we gained’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 appears similar to the house timeline feed by exhibiting the listing of TimelineTweet entries. This appears elegant. instance of a common and re-usable method 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 varieties:
sort FavoriteTweetRequest = {
variables: {
tweet_id: string; // '1867041249938530657'
};
queryId: string; // 'lI07N61twFgted2EgXILM7A'
};
Right here is the response physique varieties:
sort FavoriteTweetResponse = {
information: {
favorite_tweet: 'Finished',
}
}
Seems simple and in addition resembles the RPC-like method to the API design.
We’ve got touched on some primary components of the house timeline API design by X’s API instance. I made some assumptions alongside the best way to the most effective of my information. I consider some issues I may need interpreted incorrectly and I may 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 could possibly apply in your subsequent API Design session.
Initially, I had a plan to undergo comparable 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 do this. Will see. However it could possibly be an fascinating train.
For the reference, I’m including every type in a single go right here. You may additionally discover every type 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 Residence Feed, how they do a pagination and sorting,
* and the way they move 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: {
rely: 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: {
residence: {
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: 'Finished',
}
}
// 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 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: ...
affirmation: string; // 'Thanks. You’ll see fewer posts like this.'
childKeys: ActionKey[]; // ['1192182653', '-1427553257'], i.e. NotInterested -> SeeFewer
feedbackUrl: string; // '/2/timeline/suggestions.json?feedback_type=NotRelevant&action_metadata=SRwW6oXZadPHiOczBBaAwPanEwEpercent3D'
hasUndoAction: boolean;
icon: string; // 'Frown'
;
};
sort TimelineAddEntries = TimelineCursor ;
sort TimelineTerminateTimeline = {
sort: 'TimelineTerminateTimeline',
course: '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: {
outcome: Tweet;
};
};
sort 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[];
};
};
};
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 cheat sheets'
favourites_count: quantity; // 22195
followers_count: quantity; // 25658
friends_count: quantity;
location: string; // 'San Francisco'
media_count: quantity;
identify: 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'
identify: 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;
