The difference between Massive's RESTful API and its WebSockets is who starts each exchange. With REST you send a request and get one response, which suits history, reference data and a point-in-time snapshot. With a WebSocket you hold one connection open and we push every new event to you as it happens, which suits live data. Both cover the same asset classes and authenticate with the same API key, so the choice is about the shape of the question rather than about access.
Applies to
- Plans: REST is on every plan including the free Basic tier; WebSockets need a paid subscription.
- Endpoints or feeds: https://api.massive.com for REST, wss://socket.massive.com for streaming.
- Asset classes: stocks, options, indices, futures, forex and crypto on both.
Which one to use
Match the transport to the shape of the question. This table covers the requests support sees most often:
| What you want | Use | Why |
|---|---|---|
| Bars for a date range | REST /v2/aggs | One request returns the whole range |
| Every trade or quote as it prints | WebSocket | REST would need you to poll, and you would still miss prints between calls |
| The latest price right now, once | REST snapshot | One request, no connection to keep alive |
| The latest price, continuously | WebSocket | A snapshot loop costs a request every time and lags by its interval |
| Reference data, tickers, splits, dividends | REST | It changes daily at most, so there is nothing to stream |
| Bars while the session is running | WebSocket A or AM | Bars are pushed as they close and corrected if a late trade changes them |
What each one costs you
REST costs requests. The free Basic tier allows five a minute and paid tiers are unlimited, so a polling loop is the pattern most likely to run into a rate limit. A WebSocket costs a connection rather than requests: your plan includes a number of simultaneous connections per cluster, and once connected, the number of tickers you subscribe to is free.
That is the practical reason to stream rather than poll for anything live. The unified snapshot takes up to 250 tickers per request, so polling 500 tickers once a second is two requests a second that still lag by up to a second, and the loop grows with your universe. One WebSocket subscription delivers the same 500 tickers with no request cost and no lag beyond the network.
Why you often need both
Most Massive integrations use both, because a stream only tells you what happened after you connected. The usual pattern is one REST call to load the history or the state you need, then a WebSocket subscription to keep it current, with the stream buffered while the REST call is in flight so nothing falls between the two.
If you see an error
HTTP 429 from REST means you are over your plan's request rate. If the loop is polling for live data, move it to a WebSocket rather than adding retries.
{"ev":"status","status":"error","message":"not authorized"} on a WebSocket while the same data works over REST usually means your plan covers the REST tier but not the streaming feed for that product.
