Comparing X API’s filtered stream endpoints

The v2 filtered stream endpoints group is replacing the standard v1.1 statuses/filter and PowerTrack API. If you have code, apps, or tools that use an older version of the filtered stream endpoint, and are considering migrating to the newer X API v2 endpoint, then this comparison can help you get started. 

See our more in depth migration guides for:

Migrating from Standard v1.1 compared to X API v2

Migrating from PowerTrack API migration to X API v2


The following table compares the filtered streaming endpoints X offers:

Description Standard v1.1 PowerTrack API X API v2
Access X App Requires an enterprise contract and account Requires a developer account (sign up), and X App within a Project
Host domain https://stream.twitter.com https://gnip-stream.twitter.com https://api.twitter.com
Endpoint path 1.1/statuses/filter.json






Authentication OAuth 1.0a User Context HTTP Basic Authentication OAuth 2.0 App-Only
HTTP methods supported POST GET
Required parameters

Rule defined on connection as parameter, at least one of:

  • follow
  • track
  • locations

No required parameters for streaming connection, optional backfill parameter.

Rules managed separately

No required parameters for streaming connection, optional parameters to define response format and add backfill recovery feature for Academic Research access.

Rules managed separately

Delivery type Streaming


REST (for rules management)


REST (for rules management)

Default request rate limits 5 connection attempts per 5 min

60 requests per min aggregated for both POST and GET requests

/rules:  60 requests per minute, aggregated across all requests to /rules endpoint for the specific stream’s API (POST and GET).

Depends on the endpoint and the access level.

GET /2/tweets/search/stream:
Pro - 50 requests per 15-minutes per App

GET /2/tweets/search/stream/rules:
Pro - 450 requests per 15-minutes per App


POST /2/tweets/search/stream/rules:
Pro - 100 requests per 15 minutes per App


Maximum allowed connections 2 concurrent per authorized user Supports multiple/redundant connections, determined by contract Pro access:
Recovery and redundancy features None Backfill, redundant connections, and the Replay API  
Post caps Limited to 1% of firehose Determined by contract

There is a monthly, Project-level Post cap applied to all Posts received from this endpoint:

10,000 Posts

1 million Posts

Keep-alive signal/heartbeats blank lines (\r\n or similar) at least every 20 seconds blank lines (\r\n or similar) every 10 seconds blank lines (\r\n or similar) at least every 20 seconds
Latency 10 seconds

2 seconds

At least 10 seconds for URL unwinding enrichment

10 seconds
Maximum allowed rules 1 rule (within the endpoint connection request) Determined by contract up to 250,000 Pro access:
1000 rules
Rule filter limitations

One query per connection, up to either:

- 400 track keywords

- 5000 follow user IDs

- 25 location boxes

Up to 2,048 characters per rule

Pro Access: 
1,024 characters per rule


Post JSON format Standard v1.1 format Native Enriched or Activity Streams (selected within the console)

X API v2 format (determined by fields and expansions request parameters, not backward-compatible with v1.1 formats)

To learn more about how to migrate from the Standard v1.1 format to the X API v2 format, please visit our data formats migration guide. We will be releasing additional data format migration guides for Native Enriched and Activity Streams soon.

Provides Post edit history and metadata
Unique Features

Filtering done via query parameters on connection request

No configuration UI

Filtering done via rules created through an independent endpoint

Enrichment features available in contract

Configuration on console.gnip.com UI

Filtering done via rules created through an independent endpoint

Metrics and URL enrichment features included

Object fields and  expansions specified with request parameters

Post Annotations

Conversation ID operator and field

Configuration through developer portal