X (Twitter) Audience & Spaces Intelligence

Multi-mode X intelligence actor with PPE pricing. Three independent data modes in one actor — from zero-cost public tweet hydration to scheduled follower change tracking.

---

Modes

Mode tweet_hydrate — No-auth batch tweet hydration

Fetch full tweet details for a list of tweet IDs using X's public CDN embed endpoint (cdn.syndication.twimg.com). No account, no proxy, no API key needed. This endpoint serves X's embed widgets to the entire web and runs on Fastly's CDN — it is public, high-availability, and does not validate any credential.

Fields returned: tweet_id, text, lang, created_at, favorite_count, conversation_count, author_screen_name, author_name, author_id, author_is_blue_verified, hashtags, mentions, tweet_url.

Not available from this no-auth path: retweet count, reply count, quote count, follower count. For those fields, use an authenticated mode.

Use cases: bulk tweet content extraction, content moderation research, media monitoring pipelines, tweet archive hydration by ID list.

---

Mode spaces — X Spaces metadata

Fetch X Spaces metadata: host, title, current state (live/ended/scheduled), total live listeners, total replay watch count, playlist URL (.m3u8), scheduled/started/ended timestamps.

Why this mode exists: As of mid-2026, there is exactly one competitor covering X Spaces on Apify — and it uses the rental pricing model, which Apify is retiring on October 1, 2026. All rental actors are force-migrated to PPE. This actor fills the empty PPE Spaces lane before the disruption window closes.

Auth requirement: buyer-supplied auth_token + ct0 cookies from an X account. The actor uses these only to call X's GraphQL API (AudioSpaceById operation) — your account credentials are never stored or logged beyond the single run.

Self-healing: The GraphQL queryId (doc_id) for AudioSpaceById rotates every 2-4 weeks. This actor auto-resolves the current queryId from the live x.com JS bundle on each cold start — it does not break when X rotates their internal API IDs.

Use cases: media / podcast teams tracking Space performance, brand monitoring, audience measurement, creator analytics.

---

Mode follower_delta — KV-based follower change-feed

Track who followed or unfollowed a set of X accounts over time. Each run:

1. Fetches the current follower (or following) list via GraphQL.
2. Compares it against the KV-stored snapshot from the previous run.
3. Pushes only the delta events — new_follower, lost_follower, new_following, lost_following.

This is the "diff profile snapshots over time" approach that X's own category guides recommend — packaged as a turnkey scheduled actor.

Why delta matters: X's Followers GraphQL has no since cursor. You must re-fetch the full list and diff it yourself. This actor handles that plumbing, so buyers only see what changed.

Scope: Optimized for SMB/influencer accounts (≤500-2,000 followers per run). For mega-accounts with 100k+ followers, increase maxUsers with awareness of CU cost.

Use cases: creator growth monitoring, competitor follower gain/loss tracking, brand monitoring, influencer vetting (is their follower base growing or churning?).

---

Auth Requirement Summary

Mode	authToken	ct0	Proxy needed
tweet_hydrate	No	No	No (optional fallback)
spaces	Yes	Yes	Residential recommended
follower_delta	Yes	Yes	Residential recommended

To get authToken and ct0: open x.com in Chrome → DevTools (F12) → Application → Cookies → x.com → copy auth_token and ct0 values.

---

Pricing

Pay Per Event (PPE): $1.50 per 1,000 results. One charge per record pushed:

• One tweet = one charge (Mode C)
• One space = one charge (Mode A)
• One delta event (new/lost follower) = one charge (Mode B)

Compute cost is buyer-borne (runs on your Apify account).

---

Technical Notes

• Signature: x-client-transaction-id generated from the live ondemand JS per session.
• doc_id self-heal: queryIds auto-resolved from x.com's main JS bundle on every cold run.
• Proxy: Apify residential for authed modes (DC IPs are blocked by X at scale). tweet_hydrate uses DC with automatic residential fallback.
• No paid third-party proxy required. Buyer pays Apify's standard residential CU rate.

Integrations

Built for social-listening analysts and media-monitoring teams hydrating tweet archives, tracking follower shifts, and X Spaces metadata — the JSON/dataset output drops into the tools you already run, no glue code:

• n8n / Make / Zapier — trigger a run or pipe every new dataset item into 500+ apps (Google Sheets, Airtable, Slack, HubSpot, your database) with no code: n8n, Make, Zapier.
• Webhooks — fire your own endpoint the moment a run finishes, to push results straight into your pipeline (docs).
• MCP server — expose this actor as a tool to Claude, Cursor, or any MCP client so an AI agent can pull this data mid-conversation (guide).
• API & SDKs — fetch the dataset as JSON, CSV, or Excel through the Apify REST API or the Python / JS SDKs.

See all Apify integrations.

Usage statistics

This Actor creates a small, content-free summary at the end of each run. It is used only to monitor reliability and improve this Actor. A copy is saved as USAGE_STATS in your own Apify key-value store, so you can see the exact record created for your run.

Set disableUsageStats to true in the input to opt out. Nothing is sent then; your USAGE_STATS record only says that statistics were disabled.

Only these fields are recorded:

• schema version, Actor name and build number;
• UTC start and finish hour (not a precise timestamp);
• run duration, number of results and time to the first result, each as a coarse range;
• whether the result was empty, the end status, and an error type from a fixed list;
• memory setting and counts of charged events;
• names of the input fields you set, never their values;
• the selected option for input fields that offer a fixed list of choices (for example a sort order).

We do not collect input text, search terms, URLs, domains, usernames, email addresses, names, proxy credentials, tokens, scraped records, output items, raw error messages, stack traces, or hashes of any of those values. Records are kept for no longer than 13 months, used only as aggregated operational statistics, and never sold or shared.

Run-outcome signals (v2)

To learn whether a run did what it was asked to do, the record also holds a few more coarse ranges and yes/no flags. None of them contains content:

• the result limit you asked for (a range, when the input has one) and what share of it was delivered;
• results delivered per input item you listed (a range);
• output quality as ranges: how fully the result fields were filled, the share of rows that look like errors, the share of duplicate rows, and how many different fields appeared. These are counted in memory while results are saved; no result content is kept;
• how the run was started (console, API, schedule, webhook, another Actor);
• how it ended: stopped by you, timed out, reached the requested limit, stopped by the charge limit, and how many times the platform moved the run;
• if this Actor reports it: how many items to process worked or failed (ranges) and one failure reason from a fixed list;
• a short code made from the names of the input fields you set, never their values.