Idea: Add Xquik public X/Twitter data nodes

[kriptoburak]

Flowise already supports custom tools and third-party components. A native Xquik integration would give builders reusable read-only public X/Twitter data nodes without pasting REST calls into custom function nodes.

Suggested first version:

• Credential: Xquik API key, stored as a password field.
• Search Tweets: GET /x/tweets/search
• Get Tweet: GET /x/tweets/{id}
• Get User: GET /x/users/{id}
• Search Users: GET /x/users/search
• List User Tweets: GET /x/users/{id}/tweets
• Get Trends: GET /x/trends

Useful flows:

• Query or trend -> summarizer -> Slack, Sheets, or webhook
• Profile lookup -> lead or account enrichment
• Recurring public research reports

Docs:

• https://docs.xquik.com/api-reference/overview
• https://github.com/Xquik-dev/x-twitter-scraper

Suggested scope: read-only public data first. I would avoid posting, likes, follows, DMs, and profile updates in the initial node set.

If this fits the Flowise component model, I can help with a PR that includes a credential definition, co-located tests, and docs following the contribution guide.

[yudin-s]

Read-only first is the right scope.

For a Flowise node like this, I would make provenance part of the output contract from day one. Downstream RAG/agent flows need to know where a tweet/user/trend came from, not just the text.

For example, every output item should probably include:

{
  "source": "xquik",
  "resource_type": "tweet",
  "id": "...",
  "url": "...",
  "author_id": "...",
  "created_at": "...",
  "retrieved_at": "...",
  "query": "...",
  "rate_limit": {
    "remaining": 123,
    "reset_at": "..."
  }
}

That makes the node much easier to use in research/reporting flows because the final answer can cite the original public URL and the workflow can debug stale data.

I would also keep posting/likes/follows/DMs out of the initial version. Search/read nodes plus credentials, pagination, rate-limit metadata, and docs examples would already be useful and much lower risk.

[kriptoburak]

Thanks, I implemented this in PR #6385: #6385

I kept it read-only and made the provenance contract part of every tool response. The node now exposes selected tools for Search Tweets, Get Tweet, Get User, Search Users, List User Tweets, and Get Trends. Each returned item includes source, resource_type, id, url, author_id, created_at, retrieved_at, query, and rate_limit, with pagination at the response level when Xquik returns cursors.

No posting, likes, follows, DMs, or profile update actions are included in this first version.

[kriptoburak]

Thanks, this is useful guidance. I agree the first version should stay read-only and make provenance explicit instead of returning opaque text.

I will scope any implementation around search/read nodes, credentials, pagination, docs examples, and normalized output items with source, resource_type, public URL, IDs, created/retrieved timestamps, query context, and rate-limit metadata only where the API response or headers expose it. I will also leave posting, likes, follows, and DMs out of the first pass.