Twitter (X) API License: The Developer Agreement in Plain English

The Agreement's own header reads "Last Updated: April 27, 2026". The counterparty depends on where you are based: X Corp. in Texas if your principal place of business is outside the EU, EFTA states and the UK, or X Internet Unlimited Company in Dublin if it is inside them (Section I, definition 9). The license runs from the day you accept or first use the material, whichever is earlier (VII.A).

"Licensed Material" means the X API plus X Content, and X Content is broadly defined: posts, post IDs, profile information, "any other data and information made available to you through the X API or by any other means authorized by X, and any copies and derivative works thereof" (Section I, definition 12). Every row below is a paraphrase; the Where column tells you which clause to read in the original.

Two things in the table surprise people. First, the license grant is short and positive (four uses), while the restrictions run to twelve lettered items in III.A alone; anything not granted is reserved, because X "retains and reserves all rights ... not expressly granted" (V.A). Second, the analysis permission in II.A(1) carries the words "as explicitly approved by X", which ties back to the Developer Policy rule that your use-case description "is binding on you" and that a substantive change needs approval before you start.

"Twitter API commercial use" is the variant people search most after the license itself, and the text answers it in three layers.

Layer 1: the definition. Section III.B defines Commercial Use as any use "(a) by or for a business (i.e. an entity whose primary purpose is to earn revenue through a product or service), or (b) as part of a product or service that is monetized (e.g., website advertising, licensing fees, in-app promotions, and sponsorships)." If your project is designated non-commercial, you may not make Commercial Use of the material; the same clause notes the restriction "may not apply to officially registered non-profits or NGOs".

Layer 2: the scope of pay-per-use. Section III.L says pay-per-use access "is designed for hobbyists, commercial prototyping, initial development, early-stage X product integrations, and supporting applications with a limited number of end-users". Section III.M repeats it as a commercial-use rule: beyond that scope "you must apply (or already subscribe to) an Enterprise plan". The Developer Policy carries a near-identical sentence. The text does not put a number on "limited".

Layer 3: triggers that force Enterprise regardless of size. Any display of X Content to a government-related end user means you must apply for (or already subscribe to) an Enterprise plan, plus a disclosure of every such user, and advance notice of new ones (XIV.C). X may require an Enterprise plan if the number of users signing in with X "greatly exceeds the normal levels of other developers subscribed to a similar tier" (Developer Policy, X Login). Sites that embed or display posts must contact X once they exceed "10 million daily impressions" (Developer Policy, Public display of Posts). And under III.J, X may review your use "at any time" and require a change of tier.

Pricing is a separate document. On X's pay-per-usage rate card (docs.x.com/x-api/getting-started/pricing), a post read costs $0.005, a user read $0.010 and a follower or following read $0.010; creating a post costs $0.015, or $0.20 with a URL. Pay-per-usage is capped at 3 million post reads per monthly billing cycle, with Enterprise above that. New accounts get $20 of X API credits for saving a first payment card and completing a first purchase, plus a match of the first auto-recharge up to $50. None of those prices changes the license: the pricing page says prices are "subject to change", Section VII.B promises reasonable advance notice of material price changes to Paid Services, and paid plans are prepaid and non-refundable unless the law requires otherwise (VII.E).

This is where research and data products most often hit the terms. The Developer Policy is direct: "If you provide X Content to third parties, including downloadable datasets or via an API, you may only distribute Post IDs, Direct Message IDs, and/or User IDs (except as described below)." The recipient then rehydrates the IDs through the X API, which is how X makes sure deleted posts do not live on in shared files.

The two pages disagree. The Developer Policy says developers "may provide up to 500 public Posts Objects and/or User Objects to each person who uses your service on a daily basis if this is done via non-automated means (e.g., download of spreadsheets or PDFs)". The Restricted Use Rules page says "you may only share up to 50,000 hydrated public Post Objects and/or User Objects per recipient, per day". On academic IDs, the Policy limits sharing to what X approved, while the Restricted Use page says academic researchers may redistribute "an unlimited number". The Policy calls itself "part of your contract with X", and Agreement II.C also lists the API Restricted Use Rules as an incorporated term, so the conflict sits inside the contract itself. If your plan depends on the higher number, get written confirmation from X through the API Policy support form the Restricted Use page points to.

Recipients inherit the terms. Anything you pass on "remains subject to this Policy", and recipients must agree to the X Terms of Service, Privacy Policy, Developer Agreement and Developer Policy before receiving it. A shared folder of hydrated posts for a client therefore carries obligations for both of you.

Location data is a special case. You may not "aggregate, cache, or store location data" except together with the post it is attached to (Agreement III.E), and the Developer Policy gives the line: separating location to show "where individuals have been over time" is out, while heat maps of aggregated activity such as "the number of people in a city using a hashtag" are permitted.

Model training. Agreement III.A(k) bars using "the X API or X Content to fine-tune or train a foundation or frontier model". The Restricted Use page repeats it and adds "with the exception of Grok". The clause names foundation and frontier models; the text does not define those terms, so a narrow classifier is a question to put to X or your lawyer, not something to assume. Using an LLM to summarize or classify posts you are licensed to display is a different activity from training on them, and the text treats it differently.

Sensitive inference. The Restricted Use Rules list characteristics you may never "derive or infer, or store derived or inferred" about a user: health (including pregnancy), negative financial status, political affiliation, racial or ethnic origin, religious or philosophical beliefs, sex life or sexual orientation, trade union membership, and alleged or actual crimes. The same page then says that "aggregate analysis of X content that does not store any personal data (for example, user IDs, usernames, and other identifiers) is permitted" if it complies with law and the rest of the terms.

Surveillance. Agreement XIV.B forbids, unless X approves in writing, using X Content for surveillance or intelligence gathering, "investigating or tracking X users", monitoring sensitive events "(including but not limited to protests, rallies, or community organizing meetings)", and profiling people on sensitive categories. The Restricted Use page adds background checks or "any form of extreme vetting", credit or insurance risk analyses, "individual profiling or psychographic segmentation" and facial recognition, and says the ban applies to "any entity". Government end users whose mission includes surveillance are excluded outright (XIV.C).

Off-X matching. Linking an @handle or user ID to a person, household, device or browser outside X needs the person's "express, opt-in consent", or must rest only on information they gave you directly or public data (Developer Policy and Restricted Use Rules). The example X gives: matching "John Doe" in your customer records to @johndoe.

Benchmarking X itself. Agreement III.C limits aggregate X user metrics, X responsiveness and API performance data to "non-commercial, internal purposes" and calls them Confidential Information. The Developer Policy lists what not to calculate, including "the total number of Posts posted per day", and says you may not publicly disclose research that identifies behavior or content violating X policies without express written permission.

Automation and write actions. Services that post, follow or send Direct Messages must follow the Automation Rules: get "explicit consent before sending people automated replies or Direct Messages", honor opt-outs immediately, never bulk-follow or post identical content across accounts, and label bot accounts with who runs them (Developer Policy). X also tightened replies in practice: on February 23, 2026 @XDevelopers announced that "programmatic replies via POST /2/tweets are now restricted" unless the original author mentions or quotes you, for Free, Basic, Pro and Pay-Per-Use apps, with Enterprise and Public Utility apps "not impacted".

Keep stored content current. Agreement IV.B: if content is deleted, protected, suspended, withheld or loses its location, you "make all reasonable efforts to delete or modify" it "as soon as possible, and in any case within twenty four (24) hours after a written request" from X or the user. The Developer Policy goes further for anything you store offline: you "must keep it up to date with the current state of that content on X".

No iframes, ever. Section III.K calls the ban on iframes or "any similar embedding mechanism" absolute, and says a violation "may result in immediate termination". Embedded posts and timelines through X for Websites are the sanctioned display route, and they come with their own consent and cookie-notice duties (Developer Policy).

X can end it for any reason. You may cancel, and X "may terminate this Agreement for any reason at X's sole discretion" (VII.I), effective at the end of the paid period unless you breached it, and may suspend immediately for reasons that include "prolonged inactivity" or if serving you "is no longer commercially viable" (VII.H). On termination every license ends, you "permanently delete all Licensed Material", and on request you provide evidence such as "screenshots of deletion confirmation" within ten business days.

Audit, liability and venue. X may audit records covering the previous two years, at most once every twelve months without cause, and you pay the audit costs if it finds an underpayment of 5% or more (VIII). X's aggregate liability "will not exceed fifty dollars ($50.00)" (XI). Outside the EU, EFTA and UK, Texas law applies with courts in the Northern District of Texas or Tarrant County; inside them, Irish law and Irish courts. Either way, to the extent the law allows, you have one year to bring a claim and waive class actions (XIII).

The terms move. X may update the Agreement or any incorporated term, and "continued access or use ... will constitute binding acceptance" (XII). The Developer Policy says it "may be changed from time to time without notice". Re-read the pages when you plan a launch rather than relying on any summary, this one included.

If you store posts, the deletion duty is the clause that turns into code. The sketch below shows the generic pattern: re-request the IDs you hold in batches, and treat any ID that no longer comes back as a deletion candidate for your own store. It uses TwitterAPI.io's /twitter/tweets lookup as the example data source; whether a given data source satisfies a specific X obligation is a question for X's terms and your lawyer, not something this snippet settles.

Most readers arrive with a specific project in mind. Here is how the clauses above line up against the usual ones. Each row is a reading of the text, not a ruling; the deciding facts (who sees the data, whether you sell it, how many users you have) are yours.

Three patterns run through the table. Display and analysis for your own users is what the license is built for. Moving data to someone else (resale, shared datasets, ad audiences) is where most hard limits sit. And anything that looks at individuals rather than content in aggregate (tracking, matching, sensitive inference) needs consent or written approval, or is not allowed at all.

Terms change, and developers usually learn about it from X's developer accounts. To see how often that channel carries rule and pricing news, we pulled the recent timelines of @XDevelopers (600 posts, 376 of them original) and the older @API account (140 posts, 85 original), collected in 2026, and tagged every original post with a keyword dictionary for five topics.

Rules news is rare. Only 8 of 461 original posts (1.7%) mention terms, policy or license at all, and 16 (3.5%) mention pricing or billing. Pricing has become the more common subject recently: 9 of the 23 original posts dated 2026 in the sample touch it, against 1 of 157 in 2022. If you depend on the terms, following the account is not a substitute for re-reading docs.x.com/developer-terms.

But when it comes, it lands. The 24 posts about terms or pricing drew a median 400.5 likes and 53 replies, against 60 likes and 5 replies for the other 437 posts, a 6.7x gap on likes. Part of that is timing: most rules posts are recent and engagement on X rose after 2022. Comparing 2023 onward only, the gap shrinks to 528 vs 242 likes (2.2x) and 65 vs 42 replies. Still more reaction, on far fewer posts.

The posts behind those numbers are the milestones developers remember. On January 17, 2023 the account wrote that "Twitter is enforcing its long-standing API rules. That may result in some apps not working", the post with the most views among the terms posts in our sample. On February 6, 2026 it announced "Officially launching X API Pay-Per-Use". On February 23, 2026 it restricted programmatic replies. And on May 21, 2026 it said legacy Basic plans "are being deprecated" with subscribers "automatically migrated to the new Pay-Per-Use plan after June 1, 2026".

Builders comparing data sources often ask whether a third-party data API changes any of this. It helps to be precise about what it does and does not change.

What it does not change. The X Developer Agreement governs the X API and X Content obtained through it or "by any other means authorized by X". The X Terms of Service, the X Rules and the law (copyright, data protection, privacy) do not disappear because data arrives through a different pipe, and nothing on this page says otherwise. TwitterAPI.io is an independent service that is not affiliated with, endorsed by or licensed by X. Its own terms (twitterapi.io/terms) say: "You are solely responsible for ensuring that your use of the Service complies with all applicable laws, including data protection, privacy, and export control laws." The privacy and anti-surveillance rules X writes are also a sensible design baseline whichever source you use.

What it does change: the commercial terms. On TwitterAPI.io you pay only for the data returned: tweet endpoints cost 15 credits per tweet, which is $0.15 per 1,000 tweets ($1 = 100,000 credits), with a 15-credit minimum per request, so a search that finds nothing costs $0.00015 and a full 20-tweet page costs $0.003. Profiles cost 18 credits each ($0.18 per 1,000). On X's pay-per-usage rate card a post read is $0.005, so 1,000 posts cost $5 there versus $0.15 here, about 33x. New accounts that pass the automatic bot check get up to $1 of free credits (at most 100,000 credits, no card, one per person or network, expiring after 31 days); purchased credits never expire. Rate limits are 0.2 requests per second before the first payment and 20 once paid, 50 on Scale and 500 on Business. See /pricing for the Starter, Builder, Pro, Scale and Business subscriptions.

A practical split. Teams that need an X-approved license for a regulated or government context, or plan to redistribute data at scale, generally talk to X about Enterprise. Teams that need to read public posts for monitoring, research or AI agents often compare per-1,000 prices first. Either way, write down your use case, map it to the clause table above, and keep stored data in sync with deletions.

Question. How often do X's own developer-facing accounts post about the terms, pricing and access rules that govern the X API, and how much reaction do those posts get compared with everything else?

Accounts and method. @XDevelopers and @API, both X Corp. organization accounts. We called /twitter/user/last_tweets with default settings (replies excluded), newest first: 30 pages for @XDevelopers and all 8 pages available for @API. A third account, @Policy, returned no posts and is excluded. That is 39 requests returning 740 posts, about $0.1112 of credits. Reposts (279) were excluded from the topic analysis because their text belongs to someone else, leaving 461 original posts.

Window and tagging. Each timeline goes back as far as the endpoint returned: @XDevelopers originals span 2020 to 2026, @API 2016 to 2023. Collected in 2026. Topics come from a keyword dictionary (published in the study's analyze.py); a post can match several topics, and keyword tagging both misses some posts and catches some loosely related ones, for example a launch post that mentions pay-per-use.

What the sample cannot show. It covers two accounts' recent timelines, not every announcement X has made (some changes are announced only in docs, emails or the developer console). Medians on 15 to 24 rules posts are small-sample figures. View counts are not compared because X did not show views on older posts. Nothing here measures X as a platform.

Privacy. Aggregates only, from organization accounts. We did not analyze reposted, quoted or replying authors, and raw timelines stay outside the repository because reposts embed other people's posts. The de-identified per-post rows (year, topics, counts, no IDs or text) are in the study's sample.json.