This example fetches replies to one public X post. You pass the post id, how many replies to return, and an optional query so the replies stay on a topic.
It is a single post's reply list. The reply ledger example is different: that one reads the replies an account itself has posted.
The problem
The replies under one post are the conversation about that post. Copying them out means scrolling, and a keyword in the reply text is easy to miss once the list is long.
What the example does
- Takes a post id, a count and a query.
- Returns the replies Desearch sent back for that post.
- Prints the result. Each reply can include text, counts, time and a URL.
How it works
The file calls twitter_replies_post with post_id, count and query. The current SDK method with those same arguments is x_post_replies. It calls GET /twitter/replies/post.
The code
result = desearch.twitter_replies_post(post_id="123456789", count=10, query="Bittensor")
Set the key in the environment when you use the current client. The file's setup lines use a placeholder string. Do not commit a real key. Replace the sample post id with a real public id.
Endpoints
GET /twitter/replies/post
Example output
The file documents reply fields: text, reply count, retweet count, like count, view count, URL and created time. It does not include a saved sample run or a measured cost.
Run it yourself
The file linked above is twitter_replies_post.py in the examples repository. Install desearch-py, create a key at console.desearch.ai, and call x_post_replies with a post id, count and query.
What it costs
This example does not record X-Desearch-Cost-Usd. Current responses include that header. See pricing.
Ideas to extend it
- Write the replies to a CSV with the post id on every row.
- Sort the returned replies by like count.
- Pair this with the quote ledger when a launch post has both quotes and replies.
