What’s New in Token Filters
Token Filters Stream introduces significant improvements over Pulse V2:- Clean Data Models: Output follows exactly
TokenDetailsOutputandMarketDetailsOutputschemas with consistent camelCase naming - Partial Updates: Only changed fields are sent, reducing bandwidth and JSON parsing overhead
- Real-time View Updates: Views are updated in real-time based on incoming swaps - no more periodic sync messages
- REST API Initialization: Initialize views via REST API before connecting to WebSocket for better control
- WebSocket-only Subscriptions: Send the complete
mode+viewspayload directly over WebSocket when you do not need a REST init response first - OHLCV Attachments: Add historical candles to initial view results and receive live candle updates per swap
- Improved Delete Messages: Delete messages now use structured objects instead of pipe-separated selectors
- Consistent camelCase: All input parameters use camelCase matching the output format
Architecture Overview
Connection Flow
You can connect to Token Filters in two ways:- WebSocket Only (recommended): Send the full payload directly via WebSocket
- REST + WebSocket: Initialize via REST API first, then connect to WebSocket
Important: Even when using WebSocket, you must send the complete payload with
mode and views - not just a subscriptionId. The REST API is optional and only useful if you need the initial data before connecting.Token Filters WebSocket accepts the same GraphQL/Codex-style aliases as the REST token filters, including
marketCap, sellCount4, sniperCount, and bundlerCount. See the Token Filters Reference for the full alias table.Modes
Token Filters supports two modes:Step 1: Initialize Views via REST API
Endpoint
Request Body
Response
Step 2: Connect to WebSocket
Connection
Subscribe Message
Send the complete payload with your views configuration:Preset Models
Use preset models for common use cases without defining full custom views:Available Presets
OHLCV Mode
Enable OHLCV candlestick data for each token in a view by settingohlcv: true in the view definition.
Parameters:
Constraints:
- When
ohlcv: true, the maxlimitis 15 tokens (automatically clamped) - Up to 200 candles per token are returned on init when history is available
- Candle format:
{ o, h, l, c, v, t }(open, high, low, close, volume, timestamp ms)
ohlcv array per token:
update-token-ohlcv messages when new swaps occur:
When a new candle period starts, the previous candle’s
close is used as the new candle’s open. Volume resets to 0 for each new period.Message Types
Update Message (Partial)
When token/market data changes, only the modified fields are sent:Partial Updates: Only changed fields are included. Apply these as patches to your local state. The
address and chainId are always included for identification.New Token/Market Message
When a new token enters a view:Remove Token/Market Message
When a token exits a view:Improved Format: Token Filters uses a structured object
{ chainId, address } instead of the V2 pipe-separated format chainId|address.OHLCV Update Message
When OHLCV mode is enabled, candle updates are sent on each swap:OHLCV Mode
Enable OHLCV mode to receive historical candlestick data on init and real-time candle updates on each swap.View Definition with OHLCV
Addohlcv: true and optionally ohlcvTimeframe to a view definition:
Parameters
Constraints
- When
ohlcv: true, the view limit is clamped to 15 (max 15 tokens per view) - Each token receives up to 200 historical candles on init when history is available
- Real-time candle updates are sent via
update-token-ohlcvmessages
Init Response with OHLCV
When OHLCV is enabled, each token in the response includes anohlcv array:
Candle Fields
Token Data Model (mode: “token”)
The token mode returns data following theTokenDetailsOutput schema:
Market Data Model (mode: “market”)
The market mode returns data following theMarketDetailsOutput schema with pair information:
View Configuration
View Parameters
Use
filters.chainId for chains and filters.source for token launchpads/factories. In market mode, use filters.pool.type or filters.type for pool type filtering.Filter Operators
Custom Views Example
View Management
Pause Views
Temporarily stop receiving updates for specific views:Unpause Views
Resume updates:Unsubscribe
Unsubscribe from All
Unsubscribe from Specific View
Unsubscribe by Subscription ID
Connection Keepalive
Send periodic ping messages to maintain the connection:Complete TypeScript Example
Performance Considerations
View Limits
- Maximum 10 views per connection
- Maximum 100 items per view
- Maximum 1000 total items across all views
Bandwidth Optimization
- Partial updates significantly reduce bandwidth
- Use
pausefor inactive views - Filter aggressively to reduce data volume
- Use appropriate
limitvalues
Best Practices
- Initialize via REST API to get initial state
- Apply partial updates to local state
- Use ping/pong for connection health
- Implement reconnection logic
- Handle all message types gracefully
Support
Need help? Our response times are < 1h.Support
Telegram
Support
Slack
Need help?
Email