The practical ceiling on a Massive WebSocket is how fast your consumer reads, not anything the server enforces. Very large subscriptions genuinely work: a single message of 1.34 MB carrying 120,003 entries was acknowledged in full, and tickers at the end of that list streamed normally. Options Quotes are the one feed with a real cap.
Applies to
- Plans: every paid subscription.
- Feeds: every channel on wss://socket.massive.com/stocks, /options, /indices, /futures, /forex and /crypto.
- Asset classes: stocks, options, indices, futures, forex and crypto.
How to subscribe to many tickers
Use * for every ticker on a channel, or a comma-separated list for a chosen set. Both forms go in the params field of one subscribe message.
{"action":"subscribe","params":"T.*"}
Or, for a chosen set:
{"action":"subscribe","params":"T.AAPL,Q.MSFT,AM.F,A.SPY"}
You can also send several subscribe messages on the same connection, which is the easier pattern when your ticker list is built at runtime. Each message is acknowledged separately, and the acknowledgement carries one status object per parameter rather than one per message.
Very large lists are accepted. A single subscribe message of 1.34 MB carrying 120,003 entries was acknowledged in full, and tickers at the end of that list streamed data normally, so a list of a few thousand tickers is not close to any boundary. Splitting a very long list across several messages is still the more predictable pattern, because a rejected entry in a short message is easier to find.
How many events that actually delivers
The number of tickers is not the number that decides whether your consumer keeps up, because one message often carries several events. Measured on the stocks cluster, trade messages averaged 1.85 events each with a maximum of 27 in one message, and quote messages averaged 2.14 with a maximum of 26. Size your parser for events per second, not messages per second, and read packets off the network into a queue before you parse them.
The Options Quotes exception
Options Quotes are the one feed with a cap on how much you can subscribe to on a single connection, at around a thousand contracts. Past it you need more than one connection, which is the only case where the amount you subscribe to, rather than the number of streams you run, makes you ask for another.
The refusal is per message and all or nothing: a message that would cross the cap is rejected in full rather than partially filled, and the count is cumulative across messages on that connection. Our own tests did not settle the exact boundary, so treat a thousand as the practical ceiling and split well below it rather than probing for the edge.
If you see an error
{"ev":"status","status":"error","message":"not authorized"} in reply to a subscribe means your plan does not cover that feed, or the channel belongs to another cluster. It is not a ticker-count limit. A subscribe that gets no reply at all is a channel name we do not recognize.
{"ev":"status","status":"error","message":"Subscription limit reached for feed. Please remove some subscriptions and try again."} is the Options Quotes cap. Every entry in that message was refused, not just the ones past the limit, so resend a smaller batch rather than assuming part of it took.
Repeated disconnects after a large subscription are not a ticker limit. They are usually a slow consumer: the server-side buffer fills when you read too slowly and the connection is dropped. Why do Massive WebSocket disconnects happen? shows how to confirm it.
