Why doesn't the macro series you downloaded last month match today's?

You pulled US GDP growth in June, saved it, and built a chart. You pull it again in August and a number from three years ago has changed. Nothing is broken. You have met the single most consequential property of macroeconomic data, and the one that market data has almost no equivalent for.

What a revision is

A revision is a statistical agency changing a value it has already published, because better source data arrived. A first-estimate GDP print is built from partial surveys and gets replaced by a second estimate, a third estimate, an annual benchmark revision, and occasionally a whole-series methodological rebasing years later.

A closing price, once printed, is almost never restated — though the adjusted history around it is rewritten by every split and dividend. A quarter's GDP is revised for years.

What the endpoint gives you, and what it does not

Look again at what /macro-indicator/{country} returns per row: CountryCode, CountryName, Indicator, Date, Period, Value. Read that list carefully for what is absent.

There is no publication date, no vintage identifier, and no revision flag. Date is the end of the period being described, not the day the number became knowable. The endpoint hands you the current best estimate of history — a single, always-latest vintage.

This is not a defect peculiar to one provider; it is how the overwhelming majority of macro APIs work. But it has a specific and expensive consequence.

The look-ahead trap, in its most practical form

Suppose you test a rule that reacts to annual GDP growth. Your data says US-style growth for year Y was some value, and you let the rule act on 1 January of year Y+1. The problem: on 1 January of year Y+1 no annual figure for year Y existed at all. The first estimate arrived weeks later, possibly a full percentage point away from the number now in your file, and the value you are actually using was not published until months or years after that.

This is exactly the look-ahead bias the survivorship-and-biases lesson describes, in its most concrete form. A backtest built on latest-vintage macro data is quietly told the future. The effect is largest precisely where it hurts most: around turning points, where first estimates are least reliable and revisions are largest.

The mechanical check you can actually run

You cannot get vintages out of /macro-indicator/{country}, but you can detect revisions in the release stream. /economic-events returns, for every release, both the actual printed that day and the previous value as understood on that day. So chain them: the previous on release N+1 should equal the actual from release N. Where it does not, a revision happened.

Run it on the US Inflation Rate, year-on-year, for the first half of 2026:

• Feb period, released 2026-03-11 — actual 2.4
• Mar period, released 2026-04-10 — previous 2.4, actual 3.3
• Apr period, released 2026-05-12 — previous 3.3, actual 3.8
• May period, released 2026-06-10 — previous 3.8, actual 4.2
• Jun period, released 2026-07-14 — previous 4.2, actual 3.5

Every previous matches the prior actual. This particular chain is clean — headline CPI year-on-year is rarely revised. Run the same check on a GDP or payrolls chain and you will find links that do not match, and each mismatch is a revision you can date.

What to do about it

The honest engineering answer is boring: stamp your own snapshots. Store every macro pull with the date you fetched it, and never overwrite. Do that for six months and you have built your own vintage database, which is the only thing that makes a macro backtest defensible. This is a description of a data-handling practice, not a recommendation about any investment approach.

Try it now

1. Here is /macro-indicator/USA?indicator=gdp_growth_annual as the academy last fetched it; the date beside the title is the fetch. Copy its years and values into a file named with that date. Come back to this page in a month and diff the new table against your file. That file is the first entry of your own vintage database.

2. Here is /economic-events?country=US&type=Inflation%20Rate&comparison=yoy for March to July 2026. Rebuild the actual/previous chain above from it: each release's previous against the actual one row further down.

Now the same call with type=GDP%20Growth%20Rate, over June to September 2025. GDP is estimated three times per quarter, so here the second quarter's three releases all carry the first quarter as previous. Follow the first quarter's figure down the four rows, as actual and then as previous, and find the release on which it changed, and by how much.

3. Write down, for any macro-driven rule you are testing, the date each input actually became public. If you cannot answer that from your data, you do not yet have a testable rule.