Token-Based Version Available: The Token-Based version for token statistics is available here: Pulse Stream V2 Token-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.
🚀 V1 Stream
Legacy WebSocket APIPrevious version with single payload architecture.
Overview
Pulse Stream V2 introduces a new payload-based architecture that allows you to manage multiple views simultaneously with enhanced control over data flow and view management. Unlike the previous version, V2 sends separate payloads for each view and provides more granular control over subscriptions.Key Features
- 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 updates
- Personalized IDs: Track multiple client sessions with custom identifiers
- Factory Name Resolution: Automatic resolution of factory names to addresses
Endpoint Details
- URL: wss://pulse-v2-api.mobula.io
- Message format: JSON string
- Architecture: Payload-based with view management
Basic Usage
Default Model Configuration
The simplest way to get started is using the default model, which automatically generates three predefined views without needing to specify them:-
new
- New tokens sorted by creation date (descending)- Filters:
created_at: { not: null }
- Sort:
created_at
descending - Limit: 50 pools
- Filters:
-
bonding
- Tokens with market cap and volume activity- Filters:
market_cap: { not: null }
,volume_1h: { gte: 10 }
- Sort:
market_cap
descending - Limit: 50 pools
- Filters:
-
bonded
- Tokens with bonding curves- Filters:
created_at: { not: null }
,bondingCurveAddress: { not: null }
- Sort:
created_at
descending - Limit: 50 pools
- Filters:
Custom Views Configuration
For more control, you can define custom views:Legacy Configuration (Auto-Generated Views)
You can also use the legacy format without specifyingmodel: "default"
. When you provide chainId
or poolTypes
without any views
, the system automatically generates the three default views:
"model": "default"
and will generate the same three views (new
, bonding
, bonded
).
Subscription ID Support
Add a subscription identifier to track your connection:Data Compression
The Pulse Stream V2 API supports gzip compression for the init message to reduce bandwidth usage. When enabled, the entire message (includingtype
, payload
, subscriptionId
, and compressed
fields) will be compressed using gzip compression.
Enabling Compression
To enable compression, set thecompressed
parameter to true
in your payload:
Handling Compressed Messages
When compression is enabled, the entire message will be sent as gzip compressed binary data instead of JSON string. You need to decompress the message before parsing it as JSON. Important: When a message is compressed, you cannot access thetype
and compressed
properties before decompression, as they are part of the compressed payload.
JavaScript/Node.js Example
Python Example
Compression Benefits
- Reduced Bandwidth: Gzip compressed messages can be 60-80% smaller
- Faster Transmission: Smaller payloads transmit faster over the network
- Lower Costs: Reduced bandwidth usage can lower hosting costs
- Better Performance: Especially beneficial for large init payloads
- Standard Compression: Uses industry-standard gzip compression
When to Use Compression
- Large init payloads: When views contain many pools or complex data
- Limited bandwidth: When network bandwidth is constrained
- Mobile applications: To reduce data usage on mobile devices
- High-frequency applications: When processing many messages per second
Compression Considerations
- Standard Implementation: Uses gzip compression for optimal compression ratio
- Init Only: Only affects the initial message, not real-time updates
- Compatibility: Ensure your client can handle gzip decompression
- CPU Overhead: Compression/decompression requires additional CPU processing
- Message Structure: The entire message (including
type
andcompressed
fields) is compressed together
View Configuration
For complete filter documentation including all available fields, operators, and examples, see Filter Details.
View Structure
Each view in theviews
array supports the following configuration:
View Parameters
name
(string, required): Unique identifier for the viewmodel
(string, optional): Predefined model type (new
,bonding
,bonded
) - overrides custom filterschainId
(string | string[]): Blockchains to monitorpoolTypes
(string | string[]): Pool types/factories to monitorsortBy
(string): Sort field (see Filter Details)sortOrder
(string): Sort order (asc
ordesc
)limit
(number): Number of results per view (max: 100)offset
(number): Offset for paginationexcludeBonded
(boolean): Exclude bonded poolsfilters
(object): Filter configuration
Payload Parameters
compressed
(boolean, optional): Enable gzip compression for all messages (default:false
)subscriptionId
(string, optional): Custom subscription identifiermodel
(string, optional): Default model type (default
)chainId
(string | string[]): Blockchains to monitorpoolTypes
(string | string[]): Pool types/factories to monitorexcludeDuplicates
(boolean, optional): Exclude duplicate pools (default:true
)views
(array): Array of view configurations
Pool Filters
Thepools
object within filters supports the following fields:
factory
(string): Filter by AMM factory address or namesourceFactory
(string): Filter by bonding curve factory address or name (for bonded pools)type
(string): Filter by pool type
Available Filter Fields
Based on thePoolsStatsRealTime
schema, you can filter on the following fields:
Price & Market Data
price
: Current pool pricemarket_cap
: Market capitalizationlatest_price
: Latest pricelatest_market_cap
: Latest market capholders_count
: Number of token holdersliquidity
: Available liquidity
Volume & Trading Data
volume_1min
throughvolume_24h
: Volume metrics for different timeframesvolume_buy_1min
throughvolume_buy_24h
: Buy volume metricsvolume_sell_1min
throughvolume_sell_24h
: Sell volume metricstrades_1min
throughtrades_24h
: Trade count metricsbuys_1min
throughbuys_24h
: Buy transaction countssells_1min
throughsells_24h
: Sell transaction counts
Participant Analytics
buyers_1min
throughbuyers_24h
: Unique buyer countssellers_1min
throughsellers_24h
: Unique seller countstraders_1min
throughtraders_24h
: Unique trader countsfees_paid_1min
throughfees_paid_24h
: Fees paid metrics
Holdings Analysis
dev_holdings_percentage
: Developer holdings percentageinsiders_holdings_percentage
: Insider holdings percentagesnipers_holdings_percentage
: Sniper holdings percentagebundlers_holdings_percentage
: Bundler holdings percentagepro_traders_holdings_percentage
: Professional trader holdings percentagetop_10_holdings_percentage
: Top 10 holders percentagetop_50_holdings_percentage
: Top 50 holders percentagetop_100_holdings_percentage
: Top 100 holders percentagetop_200_holdings_percentage
: Top 200 holders percentage
Bonding & Migration Data
bonding_percentage
: Bonding curve completion percentagedeployer_migrations
: Deployer migration counttwitter_reuses_count
: Twitter reuse count
Timestamps
created_at
: Pool creation timestamplatest_trade_date
: Last trade timestamp
Message Types
Initialization Messages
Init Message
Sent when a view is first created or when reconnecting:Sync Message
Sent periodically to keep views synchronized:Real-time Update Messages
New Pool Message
Sent when a new pool is added to a view:Pool Update Message
Sent when pool data is updated:Pool Remove Message
Sent when a pool is removed from a view:View Management
Pause Views
Pause specific views to reduce bandwidth usage:Unpause Views
Resume paused views:Unsubscribe from Stream
To unsubscribe from all subscriptions, send:Unsubscribe from Specific Views or Subscriptions
You can unsubscribe from specific views, subscription IDs, or use personalized IDs. Send one of the following:Unsubscribe from Specific View
Unsubscribe from Subscription ID
Unsubscribe using Personalized ID
Unsubscribe Parameters
type
(string, required): Must be"pulse-v2"
for pulse stream v2 subscriptionsviewName
(string, optional): Name of the specific view to unsubscribe from- Must match one of the view names from your original subscription
- Examples:
"new"
,"bonding"
,"bonded"
, or custom view names
subscriptionId
(string, optional): Subscription ID to unsubscribe from- Removes all views associated with this subscription ID
- Must match the subscription ID used during connection
personalizedId
(string, optional): Personalized ID to unsubscribe from- Automatically transformed to
subscriptionId
internally - Must match the personalized ID used during connection
- Automatically transformed to
viewName
, subscriptionId
, OR personalizedId
, not multiple.
Unsubscribe Examples
Unsubscribe from specific view
Unsubscribe from subscription ID
Unsubscribe using personalized ID
Response Examples
Success Response (View)
Success Response (Subscription)
Error Response
Unsubscribing from a specific view keeps your connection active and other views subscribed. Unsubscribing from a subscription ID or personalized ID removes all views associated with that subscription.
Advanced Examples
Multi-View Trading Analysis
Bonding Curve Factory Filtering
Filter pools by their bonding curve factory:Holdings Analysis Dashboard
Factory-Specific Monitoring
Keyword-Based Filtering
Timeframe-Based Filtering
Volume Buy/Sell Analysis
Data Model
Pool Data Schema
Each pool in the response follows thePoolDataSchema
structure with comprehensive trading and analysis data:
Complete Response Example
Response Handling
Message Flow
- Connection: Send initial subscription with views configuration
- Init: Receive
init
message with current data for all views - Updates: Receive real-time updates via
new-pool
,update-pool
, andremove-pool
messages - Sync: Receive periodic
sync
messages to maintain data consistency - Management: Use pause/unpause to control data flow
Error Handling
The API will send error messages in the following format:Reconnection Strategy
When reconnecting:- Send the same subscription message
- Receive
init
message with current state - Resume receiving real-time updates
Performance Considerations
View Limits
- Maximum 10 views per connection
- Maximum 100 pools per view
- Maximum 1000 total pools across all views
Bandwidth Optimization
- Use
pause
to reduce bandwidth when views are not needed - Filter aggressively to reduce data volume
- Consider using
limit
to restrict pool count
Caching
- Views are cached for 10 minutes when no clients are subscribed
- Default views are always maintained
- Factory name resolution is cached for performance