How Will You Use the Twitter (X) API or Twitter Data? Answering the Developer Sign-Up Question

The sign-up question is not a creative-writing exercise and it is not a technical screening. It exists because X licenses its content under a Developer Agreement and Policy, and the policy says the use case is what the license covers. The relevant passage from the X Developer Policy (docs.x.com/developer-terms/policy), under the heading "Set yourself up for success", reads: "We review all proposed uses of the X developer platform to verify policy compliance - so you're required to disclose (and update, as applicable) your planned use of the X API and X Content."

Two sentences later the policy adds the part most applicants miss: "Your use case description is binding on you, and any substantive deviation from it may constitute a violation of our rules and result in enforcement action." And in the same section: you "must notify us of any substantive modification to your use case and receive approval before you may begin using X Content for that new purpose." In other words, the answer you give is a contract term, not a one-time gate. An account approved for "an internal dashboard of our brand's mentions" that later starts auto-replying to those mentions has changed its use case without approval, and the policy's enforcement clause applies: "If we believe you are in violation of this Policy ... we may suspend or permanently revoke your access to the X API and X Content."

This is why the best answers are boring. A reviewer (human or automated) is matching your text against a list of restricted uses, so you want every element of the list to be answered before it is asked. Name who you are. Name the data. Say where it goes and where it is shown. Say explicitly that you will not resell or redistribute it, and whether any posting, following, liking or messaging is automated. If a sentence would make a reviewer ask "so who else sees this data?", answer it in the next sentence.

On the exact wording. We could not reach the live sign-up form itself this session (the legacy developer.x.com pages now return a payment-required status to fetches), so this page quotes only what docs.x.com publishes: the getting-access guide's "Provide basic information about how you'll use the API" and "Provide a name, description, and use case for your app". The phrase "How will you use the Twitter API or Twitter data?" is the question as the older portal put it, and it is the phrase people still search; the elements a good answer needs have not changed with the label.

What the current sign-up actually asks for. The getting-access guide at docs.x.com/x-api/getting-started/getting-access describes three steps, and they are worth reading as the shape of your answer.

Step 1, create a developer account. "Visit console.x.com and sign in with your X account" and "Review and accept the Developer Agreement and Policy." The sign-in means your developer identity is an X account; if that account is new, unverified, or has a history of rule violations, you have given the reviewer a reason to look harder before reading a word of your use case. Use a real account with a real profile.

Step 2, profile information. "Provide basic information about how you'll use the API." This is the free-text question of this page. There is no published minimum length in the current docs; the older portal asked for at least 250 characters, and the practical minimum is whatever it takes to cover the five elements below, which is usually 600 to 1,200 characters.

Step 3, create an app. "Provide a name, description, and use case for your app." The console then generates your credentials: API key and secret, a Bearer token, an access token and secret, and a client ID and secret for OAuth 2.0, depending on the authentication your use case needs. The app description is read against the same policy, and the policy's "Service authenticity" section applies to its name: you must "clearly identify your service so that people can understand its source and purpose", and you may not use "names, logos, or URLs that mask your service's identity ... or that falsely imply an affiliation with X". Do not call your app anything with "X", "Twitter" or "official" in it.

These are the clauses a reviewer checks your answer against, quoted from the live pages. Each row names the behavior the clause rules out and what it means for your sentence.

The Developer Agreement (docs.x.com/developer-terms/agreement) sits above the policy and is blunter. Section III.A forbids you to "sell, rent, lease, sublicense, distribute, redistribute, syndicate, create derivative works of" the licensed material except as expressly permitted; Section III.D says "You will not attempt to exceed or circumvent limitations on access, calls, and use of the X API"; Section VII.H lets X "suspend your use of and access to the Licensed Material immediately without notice" if it "reasonably believes" your use would cause damage; and Section VII.I lets X "terminate this Agreement for any reason at X's sole discretion". The account-level automation rules (what an automated account may post, how it must identify itself) live on the help center at help.x.com/en/rules-and-policies/x-automation; read them if your use case posts anything.

Two of those rows surprise people. The first is model training: the restricted-use-cases page prohibits using X content "to fine-tune or train a foundation or frontier model", so an answer that says "to train our LLM" is a rejection, while "to train a small sentiment classifier that is never released as a general-purpose model" is a different use case and should be described as such. The second is the "Measuring the X Service" restriction, which lists "Calculate aggregate X user metrics, such as the total number of active users or accounts" as prohibited; a research answer that promises platform-wide user counts is asking for a no.

Each sample below covers the five elements (who, what data, how it is used and displayed, whether anything is resold or redistributed, whether anything is automated) and is written to be true for a real project of that kind. Replace the specifics; do not copy the shape and invent the facts, because the description is binding and a reviewer can compare it with what your app later does. Lengths are 600 to 1,000 characters each, which is what the elements need.

1. Academic research (public-posts dataset). "I am a PhD candidate in communication studies at [University], supervised by [Name]. I will use the search endpoints to collect public posts in English and Spanish that contain a fixed list of about 40 keywords related to municipal water policy, roughly 20,000 posts over six months, together with the public author profile fields (follower count, account creation date). The posts are stored on a university server with access limited to the research team. Analysis is topic modeling and descriptive statistics; the paper and any public dataset will contain aggregate results and post IDs only, never post text, consistent with the Content redistribution rules. I will not infer health, political affiliation or other sensitive attributes about individuals. The application does not post, like, follow or message anyone; it is read-only. Nothing is sold or shared with third parties." (Our academic research guide covers the sampling side.)

2. Monitoring and alerts bot (your own account posts). "I am an individual developer in Germany. The app watches the public posts of 12 named organization accounts (city transport authorities) with the user timeline endpoint, checked every five minutes, and when a post matches the words 'delay', 'closure' or 'canceled' the app posts a one-line summary with a link to the original post from my own account @[handle], which is labeled as automated in its profile. It posts only to my own account, at most once per matched post and never more than 20 times a day. It never replies to, follows, likes or messages other users, and it never posts the same text to more than one account. Data is held in memory for de-duplication and discarded after 24 hours; nothing is stored long term, redistributed or sold."

3. Analytics dashboard for a company's own accounts. "[Company], a 30-person software company in Canada; I am its marketing engineer. The app reads our own three accounts' posts, their public metrics (likes, reposts, replies, impressions) and the public profiles of accounts that mention us, with user-context authentication for our accounts. The data populates an internal dashboard (charts of engagement per post, follower growth, reply volume) visible to our marketing team of four. We display aggregate numbers only; individual replies are shown inside the dashboard as links to the posts on X, not stored as text beyond 30 days. No content is exported to customers or third parties, no posting or engagement is automated, and the dashboard is not sold or offered to other companies."

4. App integration and login (OAuth 2.0 user context). "[Company] builds a note-taking app with about 8,000 users. We will offer 'Sign in with X' through OAuth 2.0 with PKCE, requesting only the users.read and tweet.read scopes, to let a user save a public post into their own notebook when they paste its link. For each saved post we fetch that single post by ID and store its text and author handle in the user's private notebook, which only that user can see. We do not search, stream, aggregate or display posts outside the saving user's own notebook, we never post, like, follow or message on a user's behalf, and we never share or sell any X content. Users can disconnect X at any time, which deletes stored tokens." (Setup details are in our OAuth 2.0 user-context guide.)

5. Content tool (scheduling and publishing for the user's own accounts). "[Company] offers a drafting and scheduling tool for small businesses. A user connects their own X account with OAuth 2.0 (tweet.write, tweet.read, users.read, offline.access) and the app publishes the posts they wrote at the time they chose, to their own account only, with media they uploaded. The app never generates and posts content without a human writing and approving it, never posts identical content across several accounts, never follows, likes, replies or sends direct messages automatically, and never buys or sells engagement. We read a user's own recent posts to show them their performance; no other accounts' data is collected. Nothing is redistributed or sold."

6. Machine-learning dataset (a classifier, not a foundation model). "I am a machine-learning engineer at [Company], which builds customer-support software. We will collect about 50,000 public English posts that mention a list of 200 consumer brands, using the search endpoints over three months, to train a small text classifier that labels a post as a complaint, a question or praise. The classifier is used only inside our product to route posts about a customer's own brand to the right support queue; the model is task-specific and is not a foundation or frontier model, and no X content is used to fine-tune or train any general-purpose model, in line with the AI Model Training restriction. Raw posts are kept for 90 days on our servers and then deleted; only the model weights remain. We do not redistribute posts or user data, do not infer sensitive attributes, and do not automate any posting or engagement."

What the six have in common: a specific count or cadence (20,000 posts, every five minutes, 12 accounts), a named display surface (a paper, my own account, an internal dashboard, the user's own notebook), an explicit negative for redistribution, and an explicit negative or a tightly bounded positive for automation. Vagueness is what gets a follow-up email; a specific description a reviewer can check is what gets approved.

Rejections and suspensions come from the same list of clauses; the difference is whether the reviewer saw the problem in your text or found it later in your traffic. These are the patterns the policy pages single out, with the clause each one hits.

Three more facts shape expectations. First, the Agreement's Section VII.I lets X "terminate this Agreement for any reason at X's sole discretion", so a clean answer lowers your risk but is not a guarantee. Second, the Agreement's rate-limit clause (III.D) treats working around limits as a violation on its own, independent of what you do with the data. Third, the reviewer's reference point is your written description: if the project pivots, the policy requires you to "notify us of any substantive modification to your use case and receive approval" first, which is cheaper than explaining a suspension afterwards.

On wait times: the current docs.x.com guide does not publish a review period, and we did not find one on the policy pages, so we do not state one. In the public posts we sampled (next section), approval mentions outnumber rejection mentions roughly five to one, but those are people who chose to post about it, not a measured approval rate.

Approval gets you credentials, not data; data is billed. The pricing page at docs.x.com/x-api/getting-started/pricing describes a pay-per-usage model ("No subscriptions -pay only for what you use", "Purchase credits upfront. Deducted as you use the API") with per-resource prices and a cap: "3 million Post reads per monthly billing cycle", above which "If you need higher volume, upgrade to an Enterprise plan". Credits come with two incentives: "$20 in free X API credits when you save your first eligible payment card" and a first auto-recharge matched "up to $50". Resources are "deduplicated within a 24-hour UTC day window", so reading the same post twice in a day is billed once.

The ratio people care about is the first row: $5 per 1,000 post reads on the official rate card against $0.15 per 1,000 tweets returned on twitterapi.io, about 33x. Below the headline the two models differ in shape. The official card prices every resource you touch and dedupes within a day; twitterapi.io bills per tweet returned with a minimum of 15 credits per request ($0.00015), so a search that returns nothing costs the minimum and a full 20-tweet page costs $0.003, and purchased credits never expire. Monthly plans with bonus credits (Starter $29 to Business $1,499) are on the pricing page; the full cost breakdown works through typical workloads on both cards.

What the official account gives you that no third-party API does: user-context OAuth, so your users can sign in with X and act as themselves; official write endpoints on their behalf; and a license that explicitly covers displaying X content inside your product. If your use case is number 4 or 5 above (login, or publishing on behalf of your users), you need the developer account, and the sample answers are how you get it. If your use case is 1, 2, 3 or 6, reading public data, the next section is the shortcut.

We wanted to know what the application experience actually looks like from the outside, so we searched X itself. Using /twitter/tweet/advanced_search with queryType=Latest and four query variants built from the phrases "developer account", "developer portal", "developer access" and "developer application" combined with "x api" or "twitter api" (English, reposts excluded), we collected 547 unique public posts from 493 authors in 46 requests, collected in 2026. The queries ran dry, so the sample reaches back across years; 153 posts are from the last 12 months and 133 from this year. We then counted keyword buckets, defined in the study's analyze.py, over each post's text. A post can match several buckets, and the buckets are a rough classifier of what people chose to post, not a measurement of X's approval rate.

Price dominates the recent conversation. 62.1% of the last 12 months' posts mention price, credits or paying, double the whole-sample share (30.5%), which tracks the move to a paid, pay-per-usage API. Rejection is rare in public. 4 of 153 recent posts mention a rejection or denial, against 19 that mention approval or getting access; across the whole sample the ratio of rejection mentions to approval mentions is 0.24. Suspensions are the bigger worry. 22.2% of recent posts mention a suspension, ban, lock or restriction, nearly nine times the rejection share, which is consistent with the policy's shape: the use case is checked lightly at the door and enforced in traffic. Half of it is people asking for help. 48.4% of recent posts contain a question or a help phrase, and only 3.3% use the words "use case" at all, which says the hard part for most developers is not the essay but what happens after it.

The sample's other properties: 30.3% of posts are replies, 35.5% carry at least one link, 34.0% carry media, the median post has 4 likes, 2.6% have zero engagement of any kind, and 23 posts (4.2%) have 100 or more likes. Over the last 52 weeks the volume is 2.9 posts a week on average (median 2, peak 12, 9 weeks with none), so this is a small, steady conversation rather than a flood, and the recent share of it is overwhelmingly about money.

For the other side of the conversation we pulled the 200 most recent posts from @XDevelopers, X's official developer account, with /twitter/user/last_tweets (10 pages, replies excluded by default, collected in 2026). Because the account posts in bursts, 200 posts span 1,610 days: 113 of them are from 2022, then 12, 20, 32 and 23 in the following years. We counted four keyword buckets over the text.

The asymmetry is the finding. The account that approves your use case has, in its last 200 posts, mentioned policy, terms or rules exactly once, while 41% of its posts announce or update endpoints and 14.5% talk about sign-up, access or the console. Developers, meanwhile, spend 62% of their recent posts on price and 22% on suspensions. If you want to know what the rules are, the policy pages quoted above are the source; the announcement feed will not tell you. 17.5% of the @XDevelopers posts are quotes of other posts and 0.5% reposts; none are replies, because the default timeline call excludes them.

If your use case is reading public posts and profiles (research, monitoring, a dashboard, a dataset), you do not have to write the essay or wait for a review. twitterapi.io serves the same public data through plain REST endpoints with one API key sent in an X-API-Key header: no developer account, no use-case description, and no X account of your own for reads. You pay only for the data returned: 15 credits per tweet returned, so $0.15 per 1,000 tweets, with a 15-credit minimum per request ($0.00015 for a search that returns nothing); profiles are 18 credits each; $1 is 100,000 credits and purchased credits never expire. New accounts that pass the automatic bot check get $1 in free credits (one per person or network; others get $0.10), expiring after 31 days, and the rate limit is 0.2 requests a second until the first payment and 20 after it.

What it maps to. The academic answer above (keyword search for public posts) is /twitter/tweet/advanced_search with the same operators X's search uses (lang:en, since:, until:, from:, -filter:retweets), 20 tweets a page, following next_cursor while has_next_page is true. The monitoring bot's "12 organization accounts, every five minutes" is /twitter/user/last_tweets per account, or one advanced_search with from:a OR from:b since_time:<unix> so an idle check returns nothing and costs the minimum (every 5 minutes for a month is 8,640 checks, $1.30). The dashboard's "who mentions us" is /twitter/user/mentions; profile fields come from /twitter/user/info, which returns followers, following, statusesCount, createdAt, isBlueVerified and so on. The full endpoint list is in the X API docs explainer and the reference at docs.twitterapi.io; the free-tier question is answered there too.

What it is not, honestly. twitterapi.io is not an OAuth provider: there is no "Sign in with X" for your users and no acting on their behalf, so use cases 4 and 5 above still need the official developer account. Writes exist, but they act as your own account: one call to /twitter/user_login_v2 (10,000 credits, $0.10, with a residential proxy you supply and ideally a totp_secret) returns login_cookies, and each post, delete, like, repost, follow, unfollow or message is then 200 credits ($0.002) per call through endpoints such as /twitter/create_tweet_v2. Every write runs as that account, so X can rate-limit, lock or suspend it; keep a human pace, expect the session to need a fresh login now and then, and note that calls are billed per HTTP 200 response, not per visible outcome. The same automation rules you would promise to follow in the application apply to what you post this way, because they are X's account rules, not developer-account rules.

When the official route is still right. You need user-context OAuth, you are building a product whose license story has to be clean for a procurement team, or your monthly volume is Enterprise-scale with a contract to match. In those cases write the answer with the six samples as a template. For everything that is "read public data and analyze it", the script below is the whole onboarding.

Question: what do developers say in public about applying for X developer access, and what does X's own developer account talk about? Specifically: among recent English posts that name the developer account, portal, access or application together with the X or Twitter API, what share mention rejection or denial, approval, suspension, price, or ask for help (keyword buckets); how many posts a week there are; what share are replies or carry links; and, for @XDevelopers' most recent 200 posts, what share mention pricing, policy, sign-up or new endpoints.

Query and accounts: four /twitter/tweet/advanced_search variants with queryType=Latest built from ("developer account" OR "developer portal" OR "developer access" OR "developer application") combined with ("x api" OR "twitter api") or (x OR twitter) api, lang:en -filter:retweets, one variant each with filter:links and -filter:links, plus a variant adding ("use case" OR approved OR rejected OR denied OR suspended); and /twitter/user/last_tweets for @XDevelopers, 10 pages.

Window and sample: the most recent matching posts at collection time, collected in 2026. The search variants ran out of results, so the 547 unique posts (from 493 authors) span 4,341 days; 153 are from the last 12 months and that subset is the headline. 56 requests in total (46 search pages, 10 timeline pages), 971 tweets returned, about $0.15 in API reads. The whole study, including the collection and analysis scripts, is reproducible with the analyze.py and charts.py kept alongside it.

Method: regular-expression keyword buckets over each post's lower-cased text (the exact patterns are printed by analyze.py and listed, abridged, in the tables above); a post may match several buckets. Replies from isReply, links from entities.urls, media from extendedEntities.media, engagement from likeCount, retweetCount, replyCount and quoteCount. Weekly volume is the count of posts per ISO week over the 52 weeks before the newest post.

What the sample cannot show: it is not X's approval or rejection rate. It counts what people chose to post publicly in English, matched by keywords; a post saying "finally approved after being rejected twice" lands in both buckets, sarcasm is invisible to a regex, and people who were approved quietly or rejected quietly do not appear at all. The queries exclude non-English posts and reposts, and "Latest" ordering plus exhausted queries mean the older years are thin and unrepresentative. The @XDevelopers count covers its last 200 posts, more than half of which are from one year, and replies were excluded by the default call. None of this measures review wait times, which we therefore do not state.

Aggregates only. The search results come from private individuals, so their raw pages were kept outside the repository and deleted after analysis; sample.json holds one de-identified row per post (bucket flags, reply, link and media flags, a like-count band and an ISO week) with no ID, URL, text, author or handle. @XDevelopers is an organization account and its raw pages are kept gzip-compressed with the study. No individual is named or quoted, and no customer of ours is referenced.