Tweet search workflow to JSON Lines, CSV, or XLSX
This job is for Node.js, Bun, and queue workers that need searchable tweet data. They need it in a stable handoff format. The format is for queues, data lakes, analyst CSV files, or XLSX workbooks. It callsGET /x/tweets/search through client.x.tweets.search with the generated TweetSearchParams shape. It writes each returned tweet as one projected JSON object per line.q
Maps to REST
q. It holds the required X (Twitter) search query with keywords, handles, hashtags, or operators.limit
Maps to REST
limit. Use it as a 1 to 200 upper bound for a bounded pull. If page.has_next_page is true, keep the same q, filters, queryType, and limit. That applies when you continue with page.next_cursor.cursor
Maps to REST
cursor. Pass the opaque cursor from page.next_cursor to request the next page.sinceTime
Maps to REST
sinceTime. Use the inclusive ISO bound on every page.untilTime
Maps to REST
untilTime. Use the exclusive ISO bound on every page.queryType
Maps to REST
queryType. Use Latest for chronological results or Top for engagement-ranked results.Returned data & handoff
client.x.tweets.search returns PaginatedTweets.page.tweets
JSON field
tweets. Contains tweet records with id, text, optional author, and createdAt. Records also carry likeCount, replyCount, retweetCount, quoteCount, bookmarkCount, viewCount, and isNoteTweet when available.page.has_next_page
TypeScript field
page.has_next_page. JSON field has_next_page. Tells your worker whether another page exists.page.next_cursor
JSON field
next_cursor. Store it only when page.has_next_page is true. For bounded pulls that return fewer tweets than limit, pass it back as cursor. Send the same query, filters, queryType, and limit with it.page.tweets into JSON Lines rows in xquik-tweet-search.jsonl for queues and data lakes. You can also transform the same projected records into CSV for analysts. When account teams need spreadsheets, produce XLSX from those rows. Store tweet_id, author_username, engagement counts, page_index, page_cursor, next_cursor, and has_next_page. With them, workers resume from the last saved cursor without replaying raw SDK objects. For explicit limit pulls, resume with the same query, filters, queryType, and limit. Only cursor changes.