X's API: From the Platform That Built Modern Social Development to the One That Burned It Down

The rise, fall, and cautionary lessons of the most influential API in social media history.

---

There was a time when "Twitter API" was synonymous with innovation.

Try Apidog today

In 2007, Twitter opened one of the most generous APIs the tech world had ever seen. Third-party developers didn't just use it—they built Twitter. The retweet button, the @ mention, push notifications, and even the timeline algorithm were all invented by external developers using Twitter's API before Twitter integrated them as core features.

Fast forward to 2025. The X API now costs $42,000/month for basic enterprise access. Free-tier apps are limited to 17 tweets per day. Academic researchers who once had unlimited access now have nothing.

What happened in between is a dramatic API story: X's API decline was a slow, methodical process spanning over a decade, unlike Reddit's single bad pricing decision.

---

Act I: The Golden Age (2006–2012)

The API That Built a Platform

Twitter's early API was radically open:

GET https://api.twitter.com/1/statuses/public_timeline.json

• No authentication required.
• Minimal rate limits.
• Full public firehose available to anyone.

This open approach was strategic. In 2007, Twitter was a fragile startup, and third-party clients kept the platform alive.

What developers built:

App	Innovation	Twitter Later Adopted?
Tweetie	Pull-to-refresh UI	Yes (acquired, became official app)
Tweetbot	Smart timeline filters	Partially
TweetDeck	Multi-column dashboard	Yes (acquired)
Twitterrific	The word "tweet" itself	Yes (trademarked it)

The API was simple and RESTful:

GET  /1.1/statuses/home_timeline.json    # Your timeline
GET  /1.1/statuses/show/:id.json         # Single tweet
POST /1.1/statuses/update.json           # Post a tweet
GET  /1.1/search/tweets.json             # Search
GET  /1.1/users/show.json                # User profile

URL structure mirrored user expectations, making onboarding fast for new developers.

The Streaming API: Ahead of Its Time

Twitter introduced a streaming API before real-time became mainstream:

GET https://stream.twitter.com/1.1/statuses/filter.json?track=keyword

This persistent HTTP connection enabled real-time:

• Breaking news dashboards
• Sentiment analysis
• Social listening tools
• Academic research

In 2010, this was groundbreaking—WebSockets were rare, and Server-Sent Events were new. Twitter’s streaming endpoint was simple and effective for real-time data.

---

Act II: The Doors Start Closing (2012–2022)

API v1.1: The First Betrayal

In 2012, Twitter released API v1.1 and announced:

1. Authentication required for all endpoints – No more anonymous access.
2. User token limits – Third-party clients capped at 100,000 users.
3. Display Requirements – Strict tweet rendering rules.
4. Stricter rate limits – e.g., 15 requests per 15-minute window for many endpoints.

The 100,000 user cap effectively killed growth for third-party clients. Twitter was signaling: stop building Twitter clients.

Rate Limits (v1.1):

├── App-level: 300 requests / 15 min (search)
├── User-level: 900 requests / 15 min (timeline)
├── Post tweet: 300 per 3 hours
└── DM: 1,000 per 24 hours

The Object Model: Actually Well-Designed

Twitter’s data model was clean and developer-friendly:

{
  "id": 1234567890,
  "id_str": "1234567890",
  "text": "Hello world",
  "user": {
    "id": 987654321,
    "screen_name": "developer",
    "followers_count": 1000
  },
  "entities": {
    "hashtags": [{ "text": "api", "indices": [6, 10] }],
    "urls": [...],
    "user_mentions": [...]
  },
  "created_at": "Mon Mar 10 07:00:00 +0000 2025",
  "retweet_count": 42,
  "favorite_count": 108
}

• entities: Pre-parsed metadata (hashtags, @mentions, URLs) with precise character positions. No regex parsing needed.
• id_str: String IDs to sidestep JavaScript's 64-bit number precision issues.

API v2: The Rewrite Nobody Asked For

In 2020, Twitter launched API v2 with a different model:

GET /2/tweets?ids=123,456&tweet.fields=created_at,public_metrics&expansions=author_id&user.fields=username

• Fields system: Explicit field selection for smaller payloads.
• Expansions: Similar to Stripe’s expand.

Example:

tweet.fields=created_at,text,public_metrics,entities
user.fields=username,profile_image_url,verified
expansions=author_id,attachments.media_keys

In practice:

1. Two APIs to maintain: v1.1 endpoints remained, but v2 was incomplete for years.
2. Field confusion: Different parameters for similar data between versions.
3. Incomplete coverage: Some v1.1 features missing in v2 for years.
4. Ecosystem split: Libraries had to support both APIs.

---

Act III: The Musk Era (2022–Present)

November 2022: The API Apocalypse

Within weeks of Elon Musk's acquisition:

• The entire API team was laid off.
• Documentation decayed.
• Endpoints broke without warning.
• Rate limits changed without notice.

February 2023: The New Pricing

Old pricing:

Standard (v1.1): Free — 500,000 tweets/month read
Premium: $149/mo — 2.5M tweets/month
Enterprise: Custom pricing
Academic Research: Free — Full archive access

New pricing:

Free:    $0/mo      — 1,500 tweets/month READ, 50 tweets/month POST
Basic:   $100/mo    — 10,000 tweets/month READ, 3,000 POST
Pro:     $5,000/mo  — 1M tweets/month READ, 300,000 POST
Enterprise: $42,000/mo — Starting price, negotiable

• Small bots: Previously free, now $100/month for less access.
• Researchers: Academic Research API eliminated; now $42,000/month minimum.

What Broke

1. Academic research collapsed: Formerly free access now unaffordable.
2. Bots died: Creative bots became too expensive to operate.
3. Monitoring tools scrambled: Social platforms had to renegotiate or leave.
4. Archive access vanished: Full-archive search locked behind Enterprise.

The Technical Decay

• Reliability dropped: 500 errors, webhook issues, streaming API disconnects.
• Documentation rotted: Outdated pages, deprecated auth methods, buggy portal, unanswered tickets.

• Rate limits unpredictable:
  

  Documented: 300 requests / 15 minutes
  Actual: Sometimes 50, sometimes 300, sometimes 429 errors with no explanation
  

Developers faced inconsistent rate limiting and a lack of support.

---

The Technical Autopsy: What Was Good, What Was Bad

✅ What X/Twitter Got Right (Historically)

1. The Entities System

Pre-parsed tweet metadata:

"entities": {
  "hashtags": [
    { "text": "API", "indices": [20, 24] }
  ],
  "urls": [
    { "url": "https://t.co/xxx", "expanded_url": "https://example.com", "indices": [25, 48] }
  ]
}

No custom parsing required—just use the metadata.

2. Snowflake IDs

Twitter’s ID generation system:

Snowflake ID: 1234567890123456789
├── Timestamp:    41 bits (69 years of ms)
├── Datacenter:    5 bits
├── Worker:        5 bits
└── Sequence:     12 bits

• Time-sortable: Higher ID = newer tweet.
• Distributed: No central counter.
• Unique: Across all data centers.

Snowflake inspired similar systems at Discord, Instagram, and others.

3. OAuth 1.0a Implementation

Twitter was an OAuth pioneer. Their three-legged flow became the industry example, and many tutorials used Twitter as the reference implementation.

❌ What X/Twitter Got Wrong

1. The v1.1 → v2 Migration Disaster

Maintaining two APIs for years, with neither fully deprecated nor fully featured, caused confusion and technical debt. A better approach is a clear migration path with finished features before deprecation.

2. Authentication Complexity

Currently, X supports:

• OAuth 1.0a (v1.1)
• OAuth 2.0 Authorization Code with PKCE (v2)
• OAuth 2.0 App-Only (Bearer Token)
• API Key + Secret (Basic Auth for tokens)

Four authentication methods across two APIs. Compare to Stripe: one API key.

3. The Timestamp Format

"created_at": "Mon Mar 10 07:00:00 +0000 2025"

A Ruby Time#to_s format—neither ISO 8601 nor Unix timestamp. Harder to parse than the standard formats used by Stripe or Reddit. v2 fixed this, but v1.1 still uses the legacy format.

4. No Webhooks (Until Account Activity API)

For years, polling was the only way to detect new activity. The webhook-based Account Activity API arrived late, with a CRC challenge and limited use cases.

---

The Contrast Table

Aspect	X/Twitter	Stripe	Reddit
ID system	Snowflake (excellent)	Prefixed (excellent)	Fullnames (good)
Versioning	v1.1/v2 coexistence (messy)	Date-based (clean)	/api/v1/ (basic)
Auth	4 methods across 2 versions	1 API key	OAuth 2.0
Pricing change	Academic: free → $42K/mo	Stable, granular	Free → $0.24/1K calls
Developer notice	Days/weeks	Months/years	~60 days
Documentation	Decaying	Best-in-class	Incomplete
Unique innovation	Entities, Snowflake IDs	Expandable objects, idempotency	Thing system

---

Lessons Specific to X

1. Don't Build Two APIs When One Will Do

If you’re rewriting your API, commit to it. Set a deprecation date, provide migration tools, and finish the new version before shutting down the old one.

2. Pricing Must Match Value Perception

Charging $42,000/month for a less reliable API isn’t sustainable.

• Deliver value (SLA, features, support)
• Keep pricing predictable and transparent
• Offer tiered access for different developer sizes

3. Technical Debt Kills Trust

If your documented rate limits don’t match real-world behavior, endpoints break without notice, and support goes silent, developers will lose trust.

4. Your API's Legacy Is Bigger Than Your Platform

Snowflake IDs, the entities model, and OAuth adoption all came from Twitter. Destroying a strong technical legacy is a loss for the entire developer community.

---

Conclusion: The Saddest API Story in Tech

Reddit made a bad decision; X systematically dismantled what was once a model API.

Twitter’s API shaped how we build social platforms: streaming endpoints, the entities model, Snowflake IDs, and a thriving developer ecosystem.

All of it, methodically dismantled.

The lesson: A great API is a public good. Destroying it means losing developer innovation, academic research, and years of community trust.

Stripe builds trust with stability. Reddit lost trust with one bad move. X lost trust by showing developers don’t matter.

Your API is your reputation. Treat it accordingly.

---

Building an API developers will love? Apidog helps you design, test, and document APIs that stand the test of time. Start free.