What happens to a bar when you ask for a week instead of a day?

/eod/{ticker} takes a period parameter with exactly three values: d for daily, w for weekly and m for monthly. It looks like a zoom control. It is really an instruction to collapse several rows into one, and the collapsing rule is worth knowing precisely, because it is not the same rule for each field.

The rule, field by field

Take Apple's week of Monday 24 August to Friday 28 August 2020. The five daily rows are:

Request the same window with period=w and you get one row:

Check each of its fields against the five daily rows and the rule appears:

• open = the first day's open. Not an average, not the highest.
• close = the last day's close.
• high = the maximum of the five daily highs.
• low = the minimum of the five daily lows.
• volume = the sum. 345,937,600 + 211,495,600 + 163,022,400 + 155,552,400 + 187,630,000 = 1,063,638,000.

Four different operations — first, last, max, min, sum — applied to fields that all look alike. That asymmetry is why you should let the API aggregate rather than writing your own loop with mean() in it.

What the date on the bar means

The weekly row is stamped 2020-08-24, the Monday. Look at the following month and the rule sharpens: the bar covering the week of 7 September 2020 is stamped 2020-09-08, a Tuesday, because Monday 7 September was Labor Day and the exchange was shut.

So the label is the first trading day of the period, not the first calendar day. Monthly behaves identically: August 2020 is stamped 2020-08-03, because 1 August was a Saturday.

If you join a weekly series to a calendar by assuming Mondays, holiday weeks will silently misalign. Join on the returned date instead.

The trap in monthly bars

Now the warning this lesson exists for. Here is Apple's August 2020 monthly bar in full:

open 432.80, high 515.14, low 126.00, close 129.04, adjusted_close 125.1654 (adjusted as at 2026-07-28)

A high of 515 and a low of 126 in the same month. Read as a price range that is a 75% collapse; in reality Apple rose over the month. The 4-for-1 split fell on 31 August, so the raw high comes from a pre-split session and the raw low from a post-split one. Aggregation does not fix units. The open, high, low and close of an aggregated bar are still raw, and a period containing a corporate action mixes two different share definitions inside one row.

Only adjusted_close on that bar — the adjusted close of the final session — is safe to compare with its neighbours, and only against neighbours from the same pull.

What weekly and monthly cannot give you back

A weekly bar is a summary of a summary. You cannot recover which day the high fell on, and you cannot recover any intra-week path. If you need the sequence, request period=d and aggregate in your own code, where you still hold the daily rows. Going the other way is impossible: no amount of weekly data reconstructs Wednesday.

This is the data-shaped version of the point made in timeframes — the same instrument genuinely looks different at different resolutions, and neither picture is the true one.

Try it now

1. Here is /eod/AAPL.US with period=d for 24–28 August 2020, straight from the API; the period=w row is the table above. Reproduce all five aggregated fields of the weekly row from these daily rows by hand before you trust the rule.

2. Here is period=w across September 2020. Find the bar stamped 2020-09-08. Ask yourself what a naive "weeks start on Monday" join would have done with it.

3. Here is period=m for August 2020. Put high and low side by side. Then explain why those two numbers are not a range.