Will the same historical query return the same rows tomorrow?

Mostly yes. Sometimes legitimately no. The difference between those two cases is the difference between a result you can defend and one you cannot.

What should never change

For a trading day that has closed, date, open, high, low, close and volume are history. The tape printed what it printed.

Say "closed" precisely, though, because there is a revision window. A session a few days old can still be corrected — Apple's 2026-07-24 volume moved from 47,443,900 to 47,489,400, about a tenth of a percent, in the days after it printed. Inside that window a change is housekeeping. Once the venue's revision window has passed — days, not weeks — a move in raw OHLCV is worth a question, and it is worth reporting rather than working around.

What legitimately changes

adjusted_close. Every new split or dividend re-applies the adjustment across the entire prior history, so the adjusted series of a dividend payer is rewritten several times a year — on purpose, correctly, without anyone announcing it.

The adjusted-prices lesson in Reading the Market works this through on a verified example. Around Apple's 4-for-1 split on 2020-08-31:

The 3% gap between 121.06 and 124.81 is the dividend component. Every subsequent dividend nudges that number again — which is why the third row carries a date and the first two do not. Fetch it now and you will get something below 121.06; that is the column working, not failing. Two people running the identical query a quarter apart will disagree about 2020, both will be correct, and neither will be able to reproduce the other's chart.

Recent days get revised. A day near the current date can be corrected after first publication.

History gets repaired. A data-quality fix changes past values deliberately. That is the system working.

Renamed symbols split the answer. After 2026-02-02, /eod/MPW and /eod/MPT answer different questions about the same company.

filter=last_close is not a historical query at all. It returns whatever the most recent close happens to be when you ask. It looks like a price query and behaves like a clock.

What makes a result reproducible

Three things, recorded alongside the number:

1. The exact URL, with every parameter. "I pulled AAPL" is not a record; /eod/AAPL.US?from=2020-08-25&to=2020-09-04&period=d&fmt=json is.
2. The timestamp you fetched it. Without it, "the data changed" and "you queried on a different day" are indistinguishable.
3. Which fields you used. A result computed from close and a result computed from adjusted_close are different results, and six months later nobody remembers which you took.

If you need a number that will still be defensible in a year, there is a stronger option: store the raw close plus the corporate actions from /div/{ticker} and /splits/{ticker}, and derive the adjustment yourself. Then the adjustment is a step you own and can re-run, rather than a value that arrives already computed against a moving baseline. It is more work; the payoff is that "why is this different from last quarter?" has an answer.

This is a description of how the data behaves, not a recommendation about any instrument or method of analysis.

Try it now

1. Here is /eod/AAPL.US?from=2020-08-26&to=2020-09-02, a dividend payer across its 4-for-1 split, with close and adjusted_close side by side. For each pre-split row compute the split-only figure (close ÷ 4) and find the dividend component in the gap to adjusted_close, as a percentage. Then compare the 2020-08-28 row with the 121.06 fetched on 2026-07-28 in the table above.

2. Between the 121.06 fetched on 2026-07-28 and 28 September 2026, Apple went ex-dividend once: 0.27 on 10 August 2026. Below are the session before that ex-dividend date and the ex-date itself. Divide adjusted_close by close on 7 August: that is the factor the ex-date applied to every earlier row. Multiply 121.06 by it and compare with the 2020-08-28 adjusted_close above. That diff, from one quarterly dividend, is what a file saved in July and a pull made today disagree by.

3. Look at one number in a report you have produced. Can you reconstruct the exact URL that generated it? If not, that is the gap this lesson exists to close.