X Twitter Scraper

X Twitter Scraper

Use this skill when a user wants to integrate Xquik into an app, script, data pipeline, or AI agent workflow for X API and Twitter scraper tasks.

Use Cases

• Search tweets, fetch tweet details, read timelines, and download media.
• Look up users, check relationships, and export followers or following.
• Start extraction jobs for replies, reposts, quotes, likes, lists, communities, articles, and search results.
• Create account monitors and verify HMAC-signed webhook events.
• Add TypeScript, Python, Go, Java, Kotlin, C#, Ruby, PHP, CLI, or Terraform clients.
• Run hosted tweet and audience collection through Apify Actors.
• Connect agent runtimes through the Xquik MCP server.
• Install TweetClaw when the workflow belongs inside OpenClaw and needs plugin-managed approvals for X account actions.

Source Checks

Before writing code, inspect the current Xquik source material:

• REST API docs: https://docs.xquik.com/api-reference/overview
• SDK index: https://docs.xquik.com/sdks
• OpenAPI spec: https://xquik.com/openapi.json
• MCP server docs: https://docs.xquik.com/mcp/overview
• Skill repo: https://github.com/Xquik-dev/x-twitter-scraper
• TweetClaw OpenClaw plugin: https://github.com/Xquik-dev/tweetclaw
• TweetClaw npm registry metadata: https://registry.npmjs.org/@xquik%2Ftweetclaw
• X Tweet Scraper Actor: https://apify.com/xquik/x-tweet-scraper
• X Follower Scraper Actor: https://apify.com/xquik/x-follower-scraper

Do not invent endpoint names, request fields, response fields, scopes, pricing, limits, or package names. Read the relevant SDK README and API reference page first.

Implementation Flow

1. Identify the workflow: search, lookup, extraction, monitor, webhook, media, write action, billing, or MCP.
2. Choose the integration surface: generated SDK for application code, REST for custom clients, Apify Actors for hosted collection, MCP for agents, TweetClaw for OpenClaw plugin workflows, or webhooks for event delivery.
3. Confirm authentication requirements from the docs and use environment variables for API keys.
4. Use typed request and response models when an SDK exists for the user's language.
5. Add retries and pagination according to the SDK or API docs.
6. Show the target and usage estimate, then get explicit approval before private reads, metered extractions, draws, writes, monitors, webhooks, or other persistent work.
7. Keep webhook verification server-side and compare HMAC signatures before processing events.
8. Return structured data to the caller instead of scraping generated UI output.

SDK Pattern

When application code is involved, match the SDK to the user's project language:

• Inspect project files and package manifests to identify the language and framework.
• Open the SDK index, then read the matching SDK README before choosing install commands, package names, imports, or client methods.
• Prefer the official SDK for the detected language when one exists.
• Use REST only when the project language has no suitable official SDK or the user asks for a custom client.
• Keep API keys in environment variables or the project's existing secret manager.

Use project-native typed request and response models. Keep network calls in server-side code unless the SDK docs explicitly support browser use.

Extraction Pattern

Use extraction jobs for complete or large follower, following, reply, quote, repost, like, list, community, article, media, and search exports.

1. Call POST /extractions/estimate with the intended target and filters.
2. Show the returned result estimate and usage estimate.
3. Wait for explicit approval before creating the extraction.
4. Poll the job to a terminal state, then fetch or export its results.

Do not treat an extraction-backed follower export as a free public read. Direct, bounded public pagination remains read-only.

Apify Actor Pattern

Use the Apify path when a workflow needs hosted runs, datasets, schedules, or Apify-native orchestration.

Authenticate with an Apify API token. Keep it in APIFY_API_TOKEN. Fetch the current input schema from the relevant Actor page before selecting fields.

Start a bounded tweet run:

curl --fail --silent --show-error --request POST \
  "https://api.apify.com/v2/actors/xquik~x-tweet-scraper/runs" \
  --header "Authorization: Bearer ${APIFY_API_TOKEN}" \
  --header "Content-Type: application/json" \
  --data '{"twitterHandles":["apify"],"outputVariant":"rich","maxItems":25}'

Start a bounded follower run:

curl --fail --silent --show-error --request POST \
  "https://api.apify.com/v2/actors/xquik~x-follower-scraper/runs" \
  --header "Authorization: Bearer ${APIFY_API_TOKEN}" \
  --header "Content-Type: application/json" \
  --data '{"twitterHandles":["apify"],"relation":"followers","outputMode":"compact","maxItems":50}'

Record the returned run ID. Poll the Actor run with a bounded retry loop. Stop on SUCCEEDED, FAILED, ABORTED, or TIMED-OUT. On success, read defaultDatasetId, then fetch its dataset items.

Treat maxItems as the cap for the entire tweet run, including runs with several search terms. Keep follower target metadata when attribution matters. Treat rows with resultType: "diagnostic" as status information, not scraped records. Inspect any run-report row before trusting an incomplete result.

Review each Actor's live Apify pricing box before every paid run. Apify platform usage may apply separately. Start with a small maxItems value and ask before raising the cap.