X API review

X API is a hosted, proprietary HTTPS API, not a library, CLI or server you install. Applications send JSON requests to X and receive JSON responses. It sits between your application and X’s platform, providing programmatic access to posts, accounts, conversations and related functions.

The API is designed for applications that need to read or analyze X data, publish posts, manage account relationships, or react to events. Its REST v2 endpoints handle operations such as creating, retrieving and deleting posts; search endpoints cover recent and full-archive queries. Filtered and sampled streams provide continuous ingestion, while Account Activity API webhooks deliver events. Other endpoints cover users, Lists, Spaces, direct messages, trends and engagement metrics.

Authentication uses OAuth 2.0, including App-only Bearer tokens and Authorization Code with PKCE, or OAuth 1.0a. Access is through Pay-Per-Usage credits or a custom Enterprise contract. The API is platform-agnostic, so any environment that can make standard HTTPS requests can call it.

The integration surface is HTTPS with JSON payloads. The homepage describes REST v2 endpoints for posts and related actions, plus streaming endpoints and Account Activity API webhooks for event delivery. That gives teams a mix of request-response calls and push or continuous-ingestion patterns rather than one API interaction model.

X documents the API at developer.x.com and docs.x.com, publishes machine-readable OpenAPI specifications, and provides official XDKs for Python and TypeScript. The API can also be called from other languages or environments that support standard network requests. The homepage does not identify an official CLI; confirm CLI and SDK support for your chosen language in the vendor’s docs before planning around them.

X does not publish a centralized integration directory or total integration count. The described integration pattern is standard REST requests, webhooks and OAuth, including connections to third-party platforms such as Zapier, Make, Sprout Social and enterprise CRMs. Check endpoint access, authentication requirements and current rate limits against your use case before building.

Pay-Per-Usage has no base subscription, but it is not a free tier: access uses prepaid credits. The plan lists up to 3,000,000 post reads per monthly billing cycle at $0.005 per post read, with Enterprise contracts for custom limits above that cap. At the listed rate, 10,000 post reads a day would cost about $1,500 over a 30-day month, before write actions or other billable reads.

The pricing page lists $0.010 per user read, follower or following read, DM event read, and summoned reply; $0.001 per owned-data read; and $0.015 per post created or direct message sent. Creating a post with a URL is listed at $0.200. Requests stop when credits reach zero or a user-defined spending limit is reached; overage costs are not published, so set a spend limit and confirm how your workload is charged.

Legacy Free, Legacy Basic and Legacy Pro are retired, not current options. Their listed rates were $0, $200 monthly or $175 annual-billed, and $5,000 monthly or $4,500 annual-billed, respectively.

The X API backend, platform and data stores are proprietary. X hosts the service; there is no self-hosted, local or on-premises server distribution. Client-facing open-published material is limited to official and community libraries, wrappers and code samples published on GitHub. Check each repository’s licence before incorporating code; the API itself is not an open-source project.

X does not publish data-export or portability details on the developer homepage. Ask which data your application can retrieve, whether it can export that data in a usable format, and what restrictions apply when access ends. Moving away means replacing X-specific endpoints, authentication flows, event handling and data models, then finding another source for X data. That migration can be substantial if X IDs or API responses are embedded across your application. There is no self-hosting route that removes this dependency.

Build around the published limits, not just endpoint availability. Pay-Per-Usage lists 100 posts per 15 minutes per user and 10,000 posts per 24 hours per app, alongside a 3,000,000 monthly post-read cap. Use queues, backoff and spend limits so rate limits or exhausted credits do not stop a publishing or ingestion workflow without warning. Confirm endpoint-specific limits and access before committing to a data volume.

OAuth credentials, user-context permissions and webhook delivery need careful handling in any production integration. The vendor’s homepage describes the authentication options and event APIs, but reliability targets and support response times are not published there; ask X for those terms if they are operational requirements. Reddit developers report that official API costs can be prohibitive for read-heavy or frequent-posting projects. One thread describes an unofficial cookie-based GraphQL approach, while a commenter warns that X could ban the account. That is not a production substitute for a supported API: it depends on internal behavior and account sessions.