Paying for a real-time Massive plan changes what your account is entitled to, but not your API key, your code or the WebSocket address your code connects to. So data that stays delayed or refused after an upgrade has a cause you can check yourself, in the order below, and a new key does not help, because every key on the account reads the same subscriptions. Two responses help you tell what you are receiving: the WebSocket refusal message, and "status": "DELAYED" on a REST aggregates response.

Applies to

• Plans: any paid plan that includes real-time data, and the delayed paid tiers, such as Stocks Starter, which get the refusal and the DELAYED status described below. The pricing page shows which tiers of each product are real-time. None of the free Basic tiers is real-time.
• Endpoints or feeds: the REST aggregates (/v2/aggs/ticker/{ticker}/range/...), the real-time WebSocket feeds at wss://socket.massive.com, the delayed WebSocket feeds at wss://delayed.massive.com, and the flat files. The agreements gate real-time data on REST, the WebSocket and the flat files.
• Asset classes: stocks, options, indices, futures, forex and crypto. The WebSocket documentation lists a delayed host for stocks, options, indices and futures.

How to get the real-time data you paid for

1. Check that the plan covers the asset class you are requesting. A subscription is per product, so Stocks Advanced does nothing for an options or crypto request. Compare the request with your subscriptions page.
2. Sign the exchange agreements. Open the agreements page and sign the ones listed. The exchanges license real-time data to end users, so we cannot pass it to you until you have accepted their terms, and signing is a separate step from paying. If the agreements page shows nothing left to sign, look for an Update Status button at the top right of that page, choose it and confirm your subscriber details again.
3. Point the WebSocket at the real-time host. Connect to wss://socket.massive.com/stocks, not wss://delayed.massive.com/stocks, and the same for /options, /indices and /futures. The documentation lists the delayed host as the Delayed feed and the socket host as the Real-Time feed. An upgrade does not change the address your code connects to, so a client set up on a delayed plan keeps receiving the delayed feed until you change its URL. A Stocks Business plan also streams Fair Market Value from wss://business.massive.com/stocks, per the Fair Market Value documentation. The WebSocket quickstart shows both stocks hosts, and the documentation pages for the per-second and per-minute aggregates of those four clusters, and for trades and quotes on stocks, options and futures, such as stocks aggregates per minute, list both URLs.
4. If all three are right and the data is still delayed or refused, start a chat at massive.com/contact so someone can look at the account.

What the WebSocket refusal means

The WebSocket refusal for real-time data arrives in reply to a subscribe message, after authentication has already succeeded. A key on Stocks Starter, a 15-minute delayed plan, that connects to wss://socket.massive.com/stocks receives auth_success, and is refused when it sends a subscribe message such as this one:

{"action":"subscribe","params":"AM.AAPL"}

Response

[{"ev":"status","status":"error","message":"You don't have access real-time data. If you're already subscribed to a plan that includes real-time data, you may need to visit the dashboard to sign your agreements. If your plan only includes delayed data, you can connect to the delayed websocket at wss://delayed.massive.com/stocks."}]

The real-time refusal is quoted exactly as sent, including the missing "to" after "access", so you can search your logs for it. Its last two sentences cover two different situations, and one message covers both, so the refusal alone cannot tell you which one you are in. Your subscriptions page can:

• "If you're already subscribed to a plan that includes real-time data": the refusal is pointing at the exchange agreements. Sign the ones listed on the agreements page.
• "If your plan only includes delayed data": your plan, such as Stocks Starter, is delayed. Connect to wss://delayed.massive.com/stocks for the delayed feed your plan includes, or upgrade to a real-time tier and stay on wss://socket.massive.com/stocks.

What status DELAYED means in a REST response

"status": "DELAYED" in a Massive REST aggregates response means the bars in it were served delayed rather than in real time. It is not an error: the HTTP status is 200 and the bars are there. A Stocks Starter key, which the custom bars documentation lists as 15-minute delayed, gets it on a request whose range includes the current day. The responses below are what the request returns while the date in it is the current day, so to try it on your own key, put today's date in both places.

curl -X GET "https://api.massive.com/v2/aggs/ticker/AAPL/range/1/minute/2026-10-07/2026-10-07?sort=desc&limit=1&apiKey=YOUR_API_KEY"

Response with the Stocks Starter key, trimmed:

{
  "ticker": "AAPL",
  "results": [
    { "c": 336.6, "t": 1791405420000 }
  ],
  "status": "DELAYED"
}

Response with a real-time key at the same moment, trimmed:

{
  "ticker": "AAPL",
  "results": [
    { "c": 336.55, "t": 1791406320000 }
  ],
  "status": "OK"
}

The newest bar on the Starter key starts at 4:37 PM ET (t is in milliseconds), and the real-time key's newest bar starts at 4:52 PM ET, 15 minutes later. A day bar for the current day is also DELAYED on the Starter key and OK on the real-time key. On the same Starter key, a range that ends before the current day returns "status": "OK", so DELAYED marks the requests that reach the current day, not every response on a delayed plan.

A status of OK does not prove the data is real-time on other endpoints. On a Stocks Starter key, the single-ticker snapshot, /v2/snapshot/locale/us/markets/stocks/tickers/AAPL, returns "status": "OK" with an updated time about 15 minutes behind a real-time key's. To see how fresh a response is, compare its timestamps with the clock.

If DELAYED appears on a plan you paid real-time for, check the exchange agreements, as in step 2 above. The asset class explains it only if the request belongs to another product you hold at a delayed tier, such as Stocks Starter; a product whose tier does not reach the current day returns HTTP 403 instead, as described under If you see an error.

What works the moment you sign up

Massive data that needs no upgrade works on the first request after you sign up: there is no queue to wait in. The free Basic tier of every product starts as soon as you take the key from the keys page, and covers:

• Aggregate bars, by minute and by day: end-of-day on Stocks, Options, Indices and Currencies, and delayed 8 hours on Futures, which the documentation lists as 8-hour historical. History is two years, or all of it on Indices.
• Reference data: tickers, splits, dividends, exchanges, market status
• Corporate actions and technical indicators
• Five requests a minute, per asset class

Trades, quotes, snapshots, the WebSockets and the flat files are not on Basic. Those start at the first paid tier of the product you need, and real-time data then needs the checks above.

Why an unsigned agreement is easy to miss

An unsigned agreement is easy to miss because the responses that mention it also fit a delayed plan. The WebSocket refusal names the agreements, but the same message also covers a plan that only includes delayed data. "status": "DELAYED" on a REST response says the data is delayed, not why. Flat file downloads fail with a 403 that does not say whether the plan or the agreements are missing.

So once you have confirmed the asset class, open the agreements page before anything else. It takes one visit to rule out.

If you see an error

{"status":"NOT_AUTHORIZED","message":"Your plan doesn't include this data timeframe..."} with HTTP 403 on a current-day request, while the same request on an older date returns data, means that product's tier does not cover data this recent. Check which asset class the request belongs to first, then the tier, then the agreements.

You don't have access real-time data... in a WebSocket status message, in reply to a subscribe on wss://socket.massive.com, means the key cannot receive real-time data on that cluster. The message names two causes: exchange agreements that are not signed on a real-time plan, or a plan that only includes delayed data. Check the subscriptions page for the plan, then the agreements page.

Four things produce an HTTP 403 from the flat files, and the response does not say which: the plan does not include the dataset, the file is older than the plan's history, the file has not been published yet, or the exchange agreements are unsigned. Check what your plan reaches in the File Browser, list the file's prefix to see whether it has been published, then check the agreements page as in step 2 above. How do I get started with Flat Files and S3 on Massive? covers each cause.

Data that arrives on the right asset class but delayed, rather than refused, is where the exchange agreements are worth checking, and on the WebSocket, the host your client connects to.

Related

• How can I upgrade my Massive account?
• Why am I not authorized (NOT_AUTHORIZED) when calling Massive's REST API or WebSockets?
• How can I connect to a Massive WebSocket?
• What are the different Massive subscriptions I can use?
• What is the request limit for Massive's RESTful APIs?
• How do I get started with Flat Files and S3 on Massive?