Twitter (X) Creator Subscriptions API: see which creators an account subscribes to

The endpoint answers one direction of the relationship. You give it account A; it returns the creators A subscribes to. It never returns the people who pay A. If you are a creator and want a list of your own paying fans, this is the wrong tool: no endpoint here exposes that list.

Request. GET https://api.twitterapi.io/twitter/user/subscriptions with header X-API-Key. Two query parameters: userId (required, numeric, for example 11768582) and cursor (optional, the next_cursor from the previous page; leave it empty for page one). The documentation is explicit that usernames are not accepted.

Response. Top-level keys users, has_next_page, next_cursor, status and msg. users holds up to 20 creator profiles. has_next_page is false on the last page, and next_cursor is then null or empty. An id that does not resolve comes back as HTTP 200 with status: "error" and msg: "user not found", so always check status, not only the HTTP code.

Scope. The endpoint works for public profiles. It reads with your TwitterAPI.io API key, so no X account, OAuth app or login session is needed on your side.

We read the X API v2 documentation index (docs.x.com/x-api/llms.txt) in this session to check. Every page in it with "subscription" in the title belongs to webhooks: Account Activity (Create, Delete, Get, Validate Subscription, Get Subscription Count) and X Activity (Create, Get, Update, Delete X Activity Subscription). For example, Get Subscriptions is GET /2/account_activity/webhooks/{webhook_id}/subscriptions/all/list and "retrieves a list of all active subscriptions for a given webhook". That is a webhook concept, unrelated to paying a creator.

The closest trace is in X's TypeScript SDK reference: a schema named AudiencePolicy with two properties, creatorSubscriptions and xSubscriptions, both typed only as arrays of Any. That reads like a field that marks which audience can see a post, not an endpoint that lists who subscribes to whom, and the docs give no method that returns it for a user. We found no documented official endpoint that lists a user's Creator Subscriptions; if X adds one, the v2 index is where it will appear.

For a price reference, X's pay-per-usage rate card (docs.x.com/x-api/getting-started/pricing) charges $0.010 per resource for User: Read and $0.005 per resource for Posts: Read, with pay-per-usage capped at 3 million post reads a month and Enterprise above that. On TwitterAPI.io each creator profile returned by this endpoint costs 15 credits ($0.00015), and tweets cost $0.15 per 1,000 against X's $5 per 1,000 post reads on the same rate card, about 33x apart.

Step 1, resolve the id. Call /twitter/user/info with userName. The id is at data.id (a string; keep it as a string). An unknown handle returns HTTP 200 with status: "error", msg: "user not found" and data: null, so test status before reading data. This call costs 18 credits. If you only need the id once, the free /tools/twitter-id-finder page does the same conversion in a browser.

Step 2, page the list. Call /twitter/user/subscriptions with that userId and an empty cursor. Append users, and while has_next_page is true, call again with cursor set to the returned next_cursor. In our run, @garrytan needed three pages, sized 20, 20 and 18, so the page size really is 20 and the last page is partial.

Step 3, handle the edges. An empty list with status: success means the account subscribes to nobody; it is billed the 15-credit minimum. HTTP 502 means the upstream is temporarily unavailable; the documentation says it is not charged, so back off and retry. HTTP 400 means a malformed userId or cursor. Before your first payment the API allows 0.2 requests per second, so a script that checks many accounts should pace itself or top up first (20 requests per second once paid).

The code below is a complete, runnable client for both steps, with the cost math built in. The same client is repeated in the code example at the bottom of the page for copying.

Every creator in users arrives as a full profile. Across the 82 creator profiles our study received, each carried the same 17 fields. The documentation describes a longer UserInfo schema (with fields such as isBlueVerified, pinnedTweetIds and profile_bio), but what this endpoint actually returned to us was the compact set below. Code against the fields you see, and treat anything else as optional.

Date format. createdAt on this endpoint is ISO 8601, not the classic Thu Oct 16 12:34:56 +0000 format that tweet author objects use. Parse it with datetime.fromisoformat after trimming the trailing Z, or with dateutil.

What the creators look like. Across all 82 creator profiles we received (68 unique accounts), 22 had 1M+ followers, 42 had 100k to 1M, 17 had 10k to 100k and 1 had fewer than 10k. The verified flag was true on 81 of 82 (98.8%). That fits a feature people use to back established voices, though our sample is small and skewed to tech.

We checked 75 large public accounts (100k+ followers, drawn from the public followings of Y Combinator, a16z and TechCrunch). 3 of them subscribed to at least one creator (4%); the other 72 returned an empty list. Among the 3 that did, the counts were 1, a number between 2 and 5, and 6, a median of 4. No account in the pool needed a second page.

The 3 subscribing accounts all came from a16z's followings list (3 of 8), none from Y Combinator's (14 accounts) or TechCrunch's (53). That clustering is the honest headline: subscriptions concentrate in particular circles, and a handful of accounts decides the percentage. By follower size, 3 of 44 accounts with 100k to 1M followers subscribed (6.8%) and 0 of 31 with 1M+ did.

Our team ran a much larger aggregate sample on the same endpoint in 2026, which is the better guide to the base rate. In a 2026 sample of about 1,900 public accounts, fewer than 1 in 100 subscribed to any creator, and among accounts with 1M+ followers it was about 1 in 75. Treat the rate as under about 1 to 1.5 percent, not as a precise figure: that sample had only nine subscribing accounts, and its large-account group came from the followings of big brand accounts, so it leans toward entertainment, sports and tech in the US.

What this means for your code. Design for empty results. If you sweep a list of accounts, almost every call will return users: [], billed at the 15-credit minimum, and only a few will need pagination. Budget by account count, not by expected creators.

The price rule is simple: 15 credits per creator returned, with a minimum of 15 credits per request ($1 = 100,000 credits). Resolving a handle with /twitter/user/info adds 18 credits. Empty results and "user not found" answers bill the 15-credit minimum; a 502 is not charged.

At scale. Our 75-account sweep (ids already known from the followings lists, so no user/info calls) took 75 requests and 1,245 credits: 72 empty results at the 15-credit minimum (1,080) plus 11 creators returned by the 3 subscribing accounts at 15 each (165). That is $0.01245 in total, or about $0.000166 per account. Because most accounts return nothing, the 15-credit minimum dominates: checking 10,000 accounts by id costs roughly $1.50 in minimums plus 15 credits for each creator found. If you start from handles, add 18 credits per account for the id lookup, or batch ids you already hold.

Re-checking over time. Subscriptions change slowly, so a daily or weekly re-check is plenty. A weekly check of 1,000 accounts that subscribe to nobody costs 1,000 x $0.00015 = $0.15 a week. Plans start at Starter $29 a month if you prefer a subscription over pay-as-you-go credits; see /pricing.

Creator research. Which voices do the founders, investors or analysts in your market pay to read? A subscription is a stronger signal than a follow, because it costs money every month. Sweep a list of accounts you already track, then rank creators by how many of them subscribe. Keep the output aggregate: count creators across many accounts rather than publishing any one person's list.

Change monitoring. Store each account's creator ids and compare on a schedule. A new id means a new subscription became visible; a missing id means one ended or was hidden. The function below keeps one JSON snapshot per account and returns the difference. It reuses creator_subscriptions() from the previous section.

Enrichment. Each creator comes back with a handle, so you can fetch their recent posts with /twitter/user/last_tweets (15 credits per tweet returned, 20 per page) and measure what subscribed-to creators actually publish, how often, and with what reach. For follow-side changes, pair this with the follower tracking approach in /blog/twitter-follower-tracking-api-guide.

Agents. If you work in Claude, Cursor or another MCP client, the hosted TwitterAPI.io MCP server (/twitter-mcp-server) exposes the API to the agent with your key as the Bearer token (Authorization: Bearer <key>), so you can ask for an account's id and creator list in plain language and keep the same per-result pricing.

Question. How often do large public X accounts subscribe to any creator, how many creators do they back, how many pages does a lookup need, and what does it cost?

Accounts. A worked example of three public figures, @garrytan, @DavidSacks and @Scobleizer (counts only; we do not publish their lists). A pool of 75 public accounts with 100k+ followers, picked at random from the 136 such accounts on one page each of the public followings lists of @ycombinator, @a16z and @TechCrunch.

Method and window. One snapshot, collected in 2026: /twitter/user/info for the three named ids, /twitter/user/followings once per seed list, then /twitter/user/subscriptions for every account, following next_cursor when has_next_page was true. Every call returned status: success. 86 requests in total, 80 of them to the subscriptions endpoint, costing 2,364 credits for the subscriptions and user/info calls.

Reference sample. The "team sample" rows are aggregates from a separate 2026 run by our team on about 1,900 public accounts (random active accounts under 100k followers, and large accounts from the followings of big brand accounts). We quote only its aggregate shares.

What the sample cannot show. It is small and clustered: all three subscribing accounts in our pool came from one followings list, so the pool percentage is not a population rate. It sees only subscriptions a profile shows publicly, nothing hidden or ended, and nothing about the reverse direction. It says nothing about prices or revenue.

Privacy. Aggregates only. The three named accounts are public figures and appear with counts only; no creator is named and no account's list is published. Raw responses were kept out of the repository; the committed sample contains de-identified rows (follower bucket, creator count, pages).

Passing a handle. userId=garrytan is rejected: the endpoint takes the numeric id only. Resolve it first, and cache ids, since they never change even when a handle does.

Treating empty as failure. users: [] with status: success is the common case, not an error. Retrying it only spends another 15-credit minimum.

Checking only the HTTP code. A bad id comes back as HTTP 200 with status: "error" and msg: "user not found". Read status on every response.

Stopping after page one. Twenty creators per page means an account with 58 needs three requests. Loop on has_next_page, and cap the loop so a cursor bug cannot spin forever.

Expecting history. The response is a snapshot of what the profile shows publicly now: no start date, no price tier, no record of ended subscriptions. If you need history, keep your own snapshots as in the diff example.

Over-reading small samples. With a base rate under about 1 to 1.5 percent, a sweep of a few hundred accounts can swing widely depending on which circle you sample, as our own pool showed. Report counts with the sample size next to them.

Rate limits. Before your first payment the limit is 0.2 requests per second, 20 once paid, 50 on Scale and 500 on Business. A sweep of thousands of accounts on an unpaid key will take hours; top up first.

Sign in at /dashboard to get an API key; new accounts that pass the automatic bot check receive up to $1 of free credits (at most 100,000 credits, no card, one per person or network, expiring after 31 days). At 15 credits per creator returned, that covers thousands of lookups on accounts with no subscriptions. Purchased credits never expire.

The full parameter reference for this endpoint is at docs.twitterapi.io/api-reference/endpoint/get_user_subscriptions, and the id lookup is at docs.twitterapi.io/api-reference/endpoint/get_user_by_username. Copy the code example below, replace the key, and run it against any public handle.