What is actually inside one day of price data?

You ask an API for a stock's history and you get back a list of rows. Before you build anything on top of them, it is worth knowing exactly what a row is — and, more usefully, what it is not.

The seven fields

An unfiltered request to /eod/{ticker} returns an array of objects with the same seven keys. Here is one real row, Apple on 28 August 2020 — the academy made the call, so you can read the answer without a key of your own:

That is the whole vocabulary. OHLC is the standard abbreviation for the four price fields, and OHLCV when you include volume. The two closes being wildly different is the subject of the next lesson and is the single most important thing in this course; park it for now.

What the four prices are

Each of them is a real transaction that happened at a real moment, not a statistic:

• open is the price of the session's first eligible trade.
• close is the price of its last one.
• high and low are the highest and lowest prices printed during the session.

None of them is an average. The row does not record when any of them happened, and it does not promise they were four separate moments — an open can also be the high, a close can also be the low, and a bar that never moved has all four equal. The row tells you Apple traded as high as 505.77 that day and as low as 498.31 — a range of 7.46, or 1.49% of the closing price — but not whether the high came at 09:31 or 15:59.

Two sanity checks fall straight out of the definitions and should hold on every row you ever receive: low is less than or equal to both open and close, and high is greater than or equal to both. If a row fails that, something is wrong upstream, and finding out before you build on it is the whole point of the check.

What volume is

volume is a count of shares, not money — but in today's share count. The column is restated for splits along with the prices, so 187,630,000 is Apple's 46,907,500 real shares of that day expressed after the 4-for-1. You can see the restatement in the rows themselves: the volume does not step across the split, 187.6m on the Friday against 225.7m on the Monday.

Turnover is therefore not this column times the raw close. That pairing multiplies an adjusted count by an unadjusted price and puts the split straight back in, which is the $93 billion the next lesson takes apart. Keep both sides on one basis — volume × adjusted_close, about $23 billion — and the figure is one you compute, not one the API sends.

What is missing, and why that matters

A daily bar is a lossy summary. On a heavy day, Apple prints hundreds of thousands of individual trades. Six numbers survive. Gone are:

• When anything happened inside the session.
• Bid and ask. There is no spread in this row, so you cannot tell what it would have cost to transact.
• Trade count and any volume-weighted average price.
• Currency. The row does not say the numbers are US dollars. Currency is a property of the exchange, and you look it up separately in /exchanges-list.

That is not a shortcoming to complain about; it is what "end of day" means. The rest of this course is largely about which endpoint you reach for when one of those missing things is the thing you actually need.

Try it now

1. Here is /eod/AAPL.US with from=2020-08-24, to=2020-08-28 and fmt=json, every row of it. Count the rows and check each date against a calendar: one per trading session, no weekend entries.

2. On every row, check that low is the smallest of the four prices and high the largest. Write the check as code, not as a glance — you will want it later.
3. Multiply volume by close on each row. You have just built a turnover series that the API never sent you, which is the normal relationship between raw fields and the numbers you actually reason with.