Searching X posts from an API

The call

One GET with a keyword. No OAuth, no app review, no access tier to be approved for.

curl -H "Authorization: Bearer $SOCIALPIPE_KEY" \
  "https://api.socialpipe.dev/v1/twitter/web/fetch_search_timeline?keyword=openai"

X's own JSON comes back unrenamed. Trimmed here to a single post:

{
  "status": "ok",
  "timeline": [
    {
      "type": "tweet",
      "tweet_id": "2090859011365056720",
      "screen_name": "Bober_smart",
      "text": "I still don't understand why everyone is not using this yet…",
      "created_at": "Fri Aug 21 17:50:09 +0000 2026",
      "favorites": 9665,
      "bookmarks": 25024
    }
  ],
  "next_cursor": "DAADDAABCgABHQU41TK__-sIAAIAAAA…",
  "prev_cursor": "DAACCgACHQU41TLAJxAKAAMdBTjUssAn…"
}

Each result carries the post, its author's handle and its engagement counts, which is enough to rank a page without a second call. Paging runs both ways: send next_cursor back as cursor to go deeper, or prev_cursor to poll for what has appeared since, which is the cheaper pattern for a monitor, because you are not re-walking the whole result set each time.

One page is one call and one credit, whatever the page holds. A cached read inside its window is free, and a search that matches nothing is never charged, so a polling loop costs less than its raw call count suggests.

Why people look for an alternative here specifically

Search is the endpoint most projects hit a wall on. X's own API bills per resource returned and gates the useful search tiers behind its higher plans, so a query that returns a hundred posts is billed as a hundred things rather than as one request. That is a different shape of cost, not just a different number: it scales with how much a query matches, which is the one variable you cannot predict when you write the query.

Here a page is a call. The current rates for both, with the dates they were last verified, are on the comparison against the X API, quoted there rather than repeated here so there is one copy to keep honest.

The neighbouring searches

Keyword search is one of several. Which you want depends on what you are searching for rather than how you are searching.

• fetch_search_timeline returns posts matching a keyword. The call above.
• fetch_search_communities finds communities rather than posts.
• fetch_trending returns what is trending now, with the category each trend is filed under. No keyword needed.
• fetch_post_comments returns the replies under a post you have already identified, usually the next call after a search.

A note on what this is for: a search result is posts, and section 5 of our terms permits counting a page and ranking the posts in it. What it does not permit is turning the authors into a list of people to profile or contact. Measuring a conversation is the use case; harvesting the participants is not.