Filter Reference & System Metadata: For complete filter documentation including all available fields, operators, and examples, see Filter Details. All available factory names and pool types can be found at: https://api.mobula.io/api/1/system-metadata
Pool-Based Version Available: The Pool-Based version for pool statistics is available here: Pulse Stream V2 Pool-Based
This endpoint is only available to Growth and Enterprise plans.
Real-time vs HTTP
🔗 GET Method
Available in HTTP queriesUse the same filtering system in HTTP GET requests for simple queries.
📝 POST Method
Available in HTTP queriesUse the same filtering system in HTTP POST requests for advanced configurations.
Overview
Pulse Stream V2 Token-Based introduces a new payload-based architecture that allows you to manage multiple views simultaneously with enhanced control over token data flow and view management. This version focuses on token statistics and analytics rather than pool-based data.Key Features
- Token-Based Analytics: Subscribe to token statistics and real-time data
- Multiple Views: Subscribe to multiple custom views simultaneously
- Payload-based Architecture: Each view receives its own payload with view-specific data
- View Management: Pause/unpause individual views without disconnecting
- Enhanced Filtering: Advanced filtering capabilities with real-time token updates
- Personalized IDs: Track multiple client sessions with custom identifiers
- Asset Mode: Focused on token statistics rather than pool data
Endpoint Details
- URL: wss://pulse-v2-api.mobula.io
- Message format: JSON string
- Architecture: Payload-based with view management
- Mode: Token-based (assetMode: true)
Basic Usage
Default Model Configuration (Token-Based)
The simplest way to get started is using the default model in asset mode, which automatically generates three predefined views for token analytics:-
new- New tokens not yet bonded- Filters:
bonded: false,source: { not: null } - Sort:
created_atdescending - Limit: 50 tokens
- Filters:
-
bonding- Tokens in bonding phase- Filters:
bonding_percentage: { lt: 100 },volume_1h: { gte: 10 },bonded: false - Sort:
bonding_percentagedescending - Limit: 50 tokens
- Filters:
-
bonded- Fully bonded tokens- Filters:
bonded: true - Sort:
bonded_atdescending - Limit: 50 tokens
- Filters:
Custom Views Configuration (Token-Based)
For more control over token analytics, you can define custom views:Token Data Model
Important - Filter vs Response Naming:
- Filters: Use snake_case names matching Prisma schema (e.g.,
top_10_holdings_percentage,holders_count,bonding_percentage) - Response Payload: Uses camelCase in token object (e.g.,
token.holdersCount,token.top10HoldingsPercentage,token.createdAt)
- Holdings fields are in token object with “Percentage” suffix (e.g.,
token.top10HoldingsPercentage) - New trader category fields:
freshTradersHoldingsPercentage,smartTradersHoldingsPercentage - New trader count fields:
insiders_count,bundlers_count,snipers_count,fresh_traders_count,pro_traders_count,smart_traders_count - New trader buys tracking:
fresh_traders_buys,pro_traders_buys,smart_traders_buys
TokenDataSchema Structure
The Token-Based mode provides access to comprehensive token statistics following theTokenDataSchema structure:
Available Token Statistics
The Token-Based mode provides access to comprehensive token statistics from theTokensStatsRealTime schema:
Price Data
latest_price: Current token priceprice_1min_ago,price_5min_ago,price_1h_ago,price_4h_ago,price_6h_ago,price_12h_ago,price_24h_ago: Historical pricesprice_change_1min,price_change_5min,price_change_1h,price_change_4h,price_change_6h,price_change_12h,price_change_24h: Price changes
Market Data
market_cap: Current market capitalizationlatest_market_cap: Latest market cap calculationliquidity: Available liquidity (from token object)
Volume & Trading Data
volume_1min,volume_5min,volume_15min,volume_1h,volume_4h,volume_6h,volume_12h,volume_24h: Volume metricsvolume_buy_1minthroughvolume_buy_24h: Buy volume metricsvolume_sell_1minthroughvolume_sell_24h: Sell volume metricstrades_1minthroughtrades_24h: Trade count metricsbuys_1minthroughbuys_24h: Buy transaction countssells_1minthroughsells_24h: Sell transaction counts
Participant Analytics
buyers_1minthroughbuyers_24h: Unique buyer countssellers_1minthroughsellers_24h: Unique seller countstraders_1minthroughtraders_24h: Unique trader countsfees_paid_1minthroughfees_paid_24h: Fees paid metrics
Organic Trading Data (Excluding Bot Activity)
The organic metrics provide cleaner data by filtering out bot activity and MEV transactions: Organic Volume Metrics:organic_volume_1min,organic_volume_5min,organic_volume_15min,organic_volume_1h,organic_volume_4h,organic_volume_6h,organic_volume_12h,organic_volume_24h: Total organic volumeorganic_volume_buy_1minthroughorganic_volume_buy_24h: Organic buy volumeorganic_volume_sell_1minthroughorganic_volume_sell_24h: Organic sell volume
organic_trades_1minthroughorganic_trades_24h: Organic trade countsorganic_buys_1minthroughorganic_buys_24h: Organic buy transaction countsorganic_sells_1minthroughorganic_sells_24h: Organic sell transaction counts
organic_buyers_1minthroughorganic_buyers_24h: Unique organic buyer countsorganic_sellers_1minthroughorganic_sellers_24h: Unique organic seller countsorganic_traders_1minthroughorganic_traders_24h: Unique organic trader counts
Token Information
Filter Field Names (use these for filtering):
token_symbol,token_name,pool_address,dexscreener_listed
symbol,name,poolAddress,dexscreenerListed
source: Token source/factory (from token.source)factory: Factory address (from token.factory)poolAddress: Associated pool address (from token.poolAddress)deployer: Token deployer address (from token.deployer)symbol: Token symbol (from token.symbol)name: Token name (from token.name)holdersCount: Number of token holders (from token.holdersCount)dexscreenerListed: Whether listed on DexScreener
Social & Security Data
twitter: Twitter handletelegram: Telegram linkwebsite: Website URLothers: Other social linkssecurity: Security analysis datatwitterRenameCount: Twitter rename counttwitterRenameHistory: Twitter rename history
Bonding & Migration Data
bonded: Whether token is bonded (from token.bonded)bondingPercentage: Bonding curve completion percentage (from token.bondingPercentage)bonded_at: Bonding completion timestamp (at root level and in token object, null when not bonded)liquidityMax: Maximum liquidity reached (from token.liquidityMax)
Holdings Analysis
Filter vs Response Format:
- For Filtering: Use snake_case with “_percentage” suffix (e.g.,
top_10_holdings_percentage,dev_holdings_percentage) - In Response: Fields in token object with “Percentage” suffix in camelCase (e.g.,
token.top10HoldingsPercentage,token.devHoldingsPercentage)
top10HoldingsPercentage: Top 10 holders percentagetop50HoldingsPercentage: Top 50 holders percentagetop100HoldingsPercentage: Top 100 holders percentagetop200HoldingsPercentage: Top 200 holders percentagedevHoldingsPercentage: Developer holdings percentageinsidersHoldingsPercentage: Insider holdings percentagebundlersHoldingsPercentage: Bundler holdings percentagesnipersHoldingsPercentage: Sniper holdings percentageproTradersHoldingsPercentage: Professional trader holdings percentagefreshTradersHoldingsPercentage: Fresh trader holdings percentagesmartTradersHoldingsPercentage: Smart trader holdings percentage
Enhanced Liquidity & Pool Data
liquidityMax: Maximum liquidity across all pools for the tokenpreBondingFactory: Factory address before bonding completionpoolAddress: Primary pool address (highest volume pool)
Timestamps
latest_trade_date: Last trade timestampcreated_at: Token creation timestampbonded_at: Bonding completion timestampmigrated_at: Migration timestamp
Available Filter Fields
For a complete and detailed list of all available filter fields, operators, and examples, please refer to the Filter Details Documentation.
TokensStatsRealTime schema, including:
- Price & Market Data:
latest_price,market_cap,holders_count,liquidity, etc. - Volume & Trading Data: All volume, trades, buys, and sells metrics across multiple timeframes
- Organic Trading Data: Clean metrics excluding bot activity
- Holdings Analysis: Concentration metrics for different holder categories
- Trader Categories: Counts and analytics for different trader types
- Bonding & Migration Data: Bonding status, percentages, and timestamps
- Social & Metadata: Social links, DexScreener status, deployer info
📖 Complete Filter Reference
View all available filters with examples and operators
🔍 Custom Filters
Learn about keywords, patterns, and exclusion filters
Advanced Token Filtering
📊 Volume Filters
Filter by trading volume across multiple timeframes (1min to 24h)
👥 Holdings Analysis
Filter by holder distribution and whale concentration
💧 Liquidity Filters
Filter by liquidity levels and maximum liquidity
🎯 Price Filters
Filter by price and price changes across timeframes
🔗 Social Filters
Filter by social media presence and links
🤖 Organic Trading
Filter using organic metrics excluding bot activity
Quick Example: High Volume Tokens
For a complete list of all available filters, operators, and examples, see the Filter Details Documentation.
Message Types
Token Update Messages
The token-based mode uses the same message types as pool-based mode but withTokenDataSchema instead of PoolDataSchema.
Init Message
Sent when a view is first created or when reconnecting:New Token Message
Sent when a new token is added to a view:Token Update Message
Sent when token data is updated:Token Remove Message
Sent when a token is removed from a view:Note: In token-based mode, the message types are updated to reflect token operations:
new-token, update-token, remove-token. The data structure follows TokenDataSchema instead of PoolDataSchema. The tokenKey in remove messages uses the format chainId|tokenAddress.View Management
View management works the same as in Pool-Based mode:Pause Views
Unpause Views
Unsubscribe
Unsubscribe functionality is identical to Pool-Based mode. See the Pool-Based documentation for complete unsubscribe examples.Data Compression
Data compression works the same as in Pool-Based mode with gzip compression available for reduced bandwidth usage.Pagination
The Pulse API supports pagination to efficiently handle large datasets. You can retrieve the total count of items for your views without fetching the actual data.Pagination Endpoint
Use the/api/2/pulse/pagination POST endpoint with the same payload structure as your main query:
Pagination Request
Send the same payload structure you would use for data retrieval:Pagination Response
The response provides the total count for each view:Using Pagination with Data Retrieval
- First, get the total count using the pagination endpoint
- Then, retrieve data in chunks using
offsetandlimitparameters:
offset by the limit value (e.g., offset: 50, offset: 100, etc.).
Pagination Notes
- Pagination counts are cached to improve performance
- The pagination endpoint accepts the same payload structure as data retrieval
- Use pagination to implement client-side pagination or to estimate result sizes before fetching data
- Maximum limit per request is 100 items, so you may need multiple requests for large datasets
Performance Considerations
Token View Limits
- Maximum 10 views per connection
- Maximum 100 tokens per view
- Maximum 1000 total tokens across all views
Bandwidth Optimization
- Use
pauseto reduce bandwidth when views are not needed - Filter aggressively to reduce data volume
- Consider using
limitto restrict token count - Use organic metrics for cleaner data without bot activity
- Use pagination to handle large datasets efficiently