How to get spot bitcoin ETF flows as data

The short way

If a month of history is enough, the free route is SoSoValue's aggregate endpoint. It takes an asset and a listing country and returns daily total net inflow, traded value, net assets and cumulative inflow:

curl -s -H 'x-soso-api-key: YOUR_API_KEY' \
  'https://openapi.sosovalue.com/openapi/v1/etfs/summary-history?symbol=BTC&country_code=US'

Run it daily and append the results, because the API will not give the past back to you later. For history from the January 2024 launches onward, use a paid source whose history endpoint starts at launch.

What the options are

SoSoValue is the free option, and the most explicit about the unsettled day. Its per-fund history returns today's row with traded value filled in and every flow field null. The docs say why: flow and asset figures settle T+1. The ETF history window is one month on every endpoint, and the key is issued after an application is approved.

CoinGlass API has a flow-history endpoint that returns one row per day, with the total and a per-ticker breakdown. It is marked available on every plan from Hobbyist up. The more useful endpoint sits beside it: per-fund history with NAV, premium or discount, and shares outstanding. With those you can rebuild the flow yourself and see which fund moved. A separate endpoint covers Hong Kong bitcoin ETF flows.

CoinGlass, the free web terminal, shows the same flow pages. It is not a data feed. It is the quickest check on whether your pipeline's figure for one day matches what a second source shows.

Where this breaks

There is no published flow, only an inference. What an issuer publishes is a dated stock figure. The IBIT page read on 4 October 2026 showed 1,418,840,000 shares outstanding and a NAV of $47.64, both as of 2 October. A flow comes from two consecutive values of the first, multiplied by something:

# The usual derivation. T_prev is the previous business day, not the previous calendar day.
flow_usd = (shares_outstanding[T] - shares_outstanding[T_prev]) * nav_per_share[T]

Every aggregator has to choose that multiplier: NAV on the day or the day before, market price or NAV, rounded or not. Few of them document the choice. That is one reason two sources can differ by small amounts for the same day even after both are complete.

Shares change only in whole baskets. For IBIT a basket is 40,000 shares, so a correctly read change in its shares outstanding is a multiple of 40,000. The 2 October figure is exactly 35,471 baskets. A computed flow that is not a whole number of baskets times NAV has read the wrong file or the wrong day.

Each fund publishes on its own clock, and the flow arrives the next day. IBIT's 10-Q says the NAV for a normal trading day is released after 4:00 p.m. ET, "typically by 5:30 p.m. ET and generally no later than 8:00 p.m. ET". The administrator holds it back while it reviews the prices. Fidelity's 10-Q describes the same pause after 4:00 p.m. on its own schedule. Until every fund has reported, an aggregate is a partial sum. SoSoValue's ETF page says so directly: data not disclosed on the same day is marked "Not updated". A figure taken at 6 p.m. and the same figure taken the next morning are different numbers, and only the second is the day's flow.

Two funds do not value their bitcoin at the same price. IBIT values its holdings with the CME CF Bitcoin Reference Rate, New York Variant. Fidelity's fund uses the Fidelity Bitcoin Reference Rate, a volume-weighted median of eligible spot markets. Shares times NAV is therefore a dollar figure on each fund's own benchmark. Totalling dollar flows across funds adds slightly different prices for the same coin.

Cash or in kind changes what a flow means, not what it equals. Until 2025 these funds created and redeemed shares for cash, and the trust bought or sold the bitcoin itself through counterparties or Coinbase Prime. IBIT's 10-Q records that the SEC issued orders permitting in-kind creations and redemptions on 29 July 2025. The registration amendment took effect on 31 July 2025. Since then an authorised participant may deliver bitcoin instead of dollars, and the same 10-Q reports shares issued and redeemed against bitcoin delivered in kind. Shares times NAV gives the same dollar figure either way. A dollar "inflow" therefore no longer tells you the fund bought bitcoin on a market that day, so do not join a flow series to exchange volume as if it did.

Holidays are the exchange's, not bitcoin's. IBIT strikes a NAV only on a "Business Day": not a Saturday, not a Sunday, and not a day Nasdaq is closed for regular trading. Bitcoin trades through all of them. So a series has gaps a crypto calendar does not expect, and the first NAV after a long weekend carries three or four days of price movement. A join keyed on calendar days produces nulls or, worse, a forward-filled flow that never happened. Key on the fund's business days, and take the T_prev in the formula from that calendar.

The current row is a trap in at least one API. SoSoValue's history endpoint returns today's row with flows null and turnover present, so data[0] silently yields null for every flow metric. In the same endpoint, volume currently repeats the dollar turnover, as a string, rather than giving share volume. Read every source's documented quirks before trusting a field name.

If you outgrow this

When the question becomes why a day's number is what it is, stop consuming a derived flow and store the inputs. Keep each fund's shares outstanding, NAV and basket size, dated, from the per-fund history in CoinGlass API or from the issuers' own pages. Derive the flow yourself and keep the aggregator's figure beside it as a cross-check. Then a disagreement between sources is something you can explain, not something you have to pick a side on.