A fractional volume on the Massive aggregates endpoint is the normal case rather than an oddity, and it has a date attached: FINRA required fractional-share quantities to be reported from 23 February 2026, so what used to be an occasional artifact is now routine. Worth seeing the scale before you treat it as one: on an ordinary session 747 of AAPL's 885 minute bars came back with a fractional volume. Fractional-share trading is why. What it is not is a side effect of the adjusted parameter, which is the usual first guess.
Applies to
- Plans: every plan.
- Endpoints: /v2/aggs/ticker/... for the bars, /v3/trades/{ticker} for the trades behind them, and the AM and A WebSocket channels, which carry both an integer and a decimal field.
- Asset classes: US stocks and ETFs, where fractional-share trading happens.
How to see it
curl -X GET "https://api.massive.com/v2/aggs/ticker/AAPL/range/1/minute/2026-09-04/2026-09-04?limit=5000&apiKey=YOUR_API_KEY"
Response
{
"results": [
{ "o": 326.5, "h": 328.36, "l": 326.35, "c": 326.7, "v": 24711.700913, "n": 1796 }
],
"status": "OK"
}
The trade underneath is where the fraction comes from. Notice that the integer size can be zero while the real size is not:
curl -X GET "https://api.massive.com/v3/trades/AAPL?timestamp=2026-09-04&limit=200&apiKey=YOUR_API_KEY"
Response
{
"results": [
{ "price": 320.0017, "size": 0, "decimal_size": "0.250624", "sip_timestamp": 1788566384572948118 }
],
"status": "OK"
}
It is not the adjusted parameter
The adjusted parameter scales volume by the split ratio and leaves it a whole number. BRK.A's minute bars for one session return the same six fractional volumes, 4.008311 among them, whether you ask with adjusted=true or adjusted=false. NVDA's daily bars across its ten-for-one split return 528,401,780 adjusted and 52,840,178 unadjusted, both whole. So adjustment is not the cause, and turning it off will not give you integer volume.
Fractional trades also carry the odd-lot condition, which is why they add to a bar's volume without ever setting its open, high, low or close. That is covered in how Massive handles fractional share trades, along with the size and decimal_size fields in more detail.
How to handle it in your code
- Store volume as a decimal or a fixed-point number, not an integer. Truncating loses real volume, and rounding a thin ticker's bar can lose most of it.
- Sum decimal_size rather than size when you build your own bars from trades. size is rounded and can be zero, so a sum of it will not match our volume.
- Do not filter out trades with size: 0. They are real trades for less than one share.
- Compare with a tolerance rather than for equality when reconciling against another vendor. Vendors round differently.
If you see an error
Volume that does not match your own reconstruction is usually size versus decimal_size. Sum the decimal field.
Volume of exactly 0 on a bar that has a price is a bar built entirely from sub-share trades where you truncated. Check your storage type before you report it.
An integer volume where you expected a fraction is fine too. Not every bar contains a fractional trade.
