The FRED API is a programmatic interface for retrieving economic data from the FRED website. The documentation describes two versions with different scopes: Version 1 works at the series level and supports ALFRED as well, while Version 2 is aimed at bulk retrieval of an entire release and its full history. A reader checklist should first pin down which version a given question is about, then confirm the endpoint's stated function against the documentation text.
Everything below is a mapping exercise, not a test. Each item points to a documented statement. If a step is not covered by those statements, it is flagged as not established rather than assumed.
Step 1: Decide which version answers your question
The two versions are not interchangeable by description. Version 2 is described as ideal for anyone interested in retrieving observations for all series on a release in bulk and obtaining the entire history. Version 1 is described as providing incremental data on a series level, customizable by data source, release, category, series, and other preferences.
Both versions are described as enabling users to write programs and build applications that retrieve economic data. The difference is scope: Version 1 references both the FRED and ALFRED websites, and Version 2 references the FRED website. If your checklist item is bulk history for a release, the documented match is Version 2. If it is series-level incremental data with customization, the documented match is Version 1.
Step 2: Match your question to a documented endpoint
Treat each endpoint as one sentence of documentation. Copy the question you are asking, then find the single endpoint whose description matches it. The table below is a verification aid, not a ranking.
| Question you are asking | Documented endpoint |
|---|---|
| What are the child categories of a parent category? | fred/category/children |
| What categories are related to a category? | fred/category/related |
| Which series are in a category? | fred/category/series |
| Which tags are related to a category? | fred/category/related_tags |
| When are all economic data releases scheduled? | fred/releases/dates |
| When is one specific release scheduled? | fred/release/dates |
| Which series belong to a release? | fred/release/series |
| Which sources feed a release? | fred/release/sources |
| Which tags are related to a release? | fred/release/related_tags |
| What tables does a release have? | fred/release/tables |
| Which categories does a series belong to? | fred/series/categories |
| What are the observations for a series? | fred/series/observations |
| Which release does a series belong to? | fred/series/release |
| Which series match keywords? | fred/series/search |
Step 3: Separate release-level from series-level lookups
A common mistake is to look for a series by release when the question is really about observations. The documentation keeps these separate. Release endpoints cover dates, series membership, sources, related tags, and tables. Series endpoints cover categories, observations, release, and keyword search.
Notice the pair fred/releases/dates and fred/release/dates. The first is described for all releases of economic data; the second for a release of economic data. If your checklist asks for one release, the singular form is the match. If it asks across all releases, the plural form is the match. Reading the boundary word is part of verification.
Step 4: Write your own worked example
A worked example helps because the documentation describes functions, not outputs. Suppose, Hypothetical, a reader wants the release calendar for one release and then the series on that release. The documented chain is fred/release/dates for the single release date, then fred/release/series for the series on that release. Suppose the reader then wants observations, the documented endpoint is fred/series/observations.
This chain is a construction from the documentation statements, not a tested sequence. The checklist value is that each arrow maps to a named endpoint whose description matches the step's question.
Step 5: A quick pre-read checklist
- State your question in one sentence before opening the documentation.
- Mark whether it concerns a release, a category, or a series.
- Mark whether it concerns scheduling (dates) or content (series, sources, tables, tags).
- Check whether the documentation uses singular or plural in the endpoint name.
- Record which version's described scope matches your question.
- Do not assume field names, pagination, or output formats from the descriptions alone.
What the source does not say
The documentation statements here do not establish request parameters, response formats, rate limits, authentication, or error behavior. They do not state whether Version 1 and Version 2 share endpoints, nor which endpoints belong to which version. They do not give example responses or field-level definitions.
They also do not say that any endpoint returns data in a particular unit, frequency, or vintage. ALFRED appears only in the Version 1 statement, and no endpoint description here mentions it by name. None of this material should be treated as a substitute for parameter-level documentation.
Version comparison at a glance
Use this table as a reader aid for the two version descriptions only. It is not a feature matrix for endpoints.
| Aspect | Version 1 (as described) | Version 2 (as described) |
|---|---|---|
| Data granularity | Incremental data on a series level | Observations for all series on a release, in bulk |
| History | Not described in this statement | Entire history |
| Customization | By data source, release, category, series, and other preferences | Not described in this statement |
| Website referenced | FRED and ALFRED | FRED |
The comparison shows why the first checklist step is version choice. If a reader skips it, the endpoint list can look like a single menu when the documentation describes two access paths.
Putting the checklist to work
Verification here means mapping a question to a documented sentence and marking anything outside that sentence as unknown. The documentation reviewed gives version scopes and endpoint descriptions. It does not give the operational detail needed to run a request, so a complete verification would need the parameter references and response examples that sit outside these statements.