fredr wraps the FRED API in R, and four of its data sources cannot be redistributed through it

fredr() fetches one series, but the search function finds it

The core of the package is a single function, fredr(), which fetches observations for a FRED series. The framing sentence, though, is that this is one endpoint among many exposed through the package, and the named example of a second one is fredr_series_search_text(), which searches for a series by text. That ordering matters for how you use it: finding the series identifier is the hard part of working with FRED, and the package treats search as a first-class operation rather than something you do in a browser and paste in. The documentation goes further and says users are strongly encouraged to reference the FRED API documentation to leverage the full power of fredr. In other words the package is a set of bindings, not a curated catalogue, and the upstream API reference is the authority on what else is available.

An API key is required, and it is set through ?fredr_set_key()

The only hard prerequisite the README names is a free API key, and the documentation pointer for it is the help page for ?fredr_set_key(). Everything else about the package assumes you have one. There is no default key baked in, no environment variable named in the README, and no example that runs without credentials, which means the very first thing to check when a script of yours fails is whether a key was ever set in that session. It is worth knowing that the key belongs to you as a user of the FRED service rather than to the package, so the same key works for the Python client or anything else you point at the same API, and the same restrictions on redistribution apply regardless of which client fetched the data.

The result is a five column tibble, and two of those columns are dates

The worked example fetches the US unemployment rate series for the 1990 to 2000 window and shows the shape of what comes back:

fredr(
  series_id = "UNRATE",
  observation_start = as.Date("1990-01-01"),
  observation_end = as.Date("2000-01-01")
)

The printed result is a tibble of 121 rows by 5 columns, with the column headers date, series_id, value, realtime_start and realtime_end. Three of those are the observation itself, dated and valued, tagged with the identifier you asked for. The other two are dates, and their names say they concern the real-time period rather than the observation: in every printed row both are 2021-01-29, while the observation dates run from 1990-01-01 onward. So the object you get is not just a series of numbers, it is a series of numbers each carrying the vintage it was retrieved under, which is what lets you line up two pulls of the same series and see where a revision landed.

Four sources are marked as not redistributable through the API

There is a restrictions section, and it is the most operationally important part of the README. According to the FRED team, four data sources do not permit redistribution through the FRED API: ICE Libor Rates, ICE Swap Rates, LBMA Gold Price Daily Prices, and LBMA Silver Price Daily Prices. The advice given for those is direct, download the data directly from the FRED website instead of taking it through the API, and the series in question can be found on a source page linked from the README. So if you are building a pipeline that publishes derived data to other people, this is the check to run before the pipeline does any publishing. Fetching is not the same as redistributing, and the package is careful to draw that line rather than pretending it does not exist.

The README points at four other R packages for the same API

The see also section names four existing R packages designed for the FRED API: business-science's tidyquant, jcizel's FredR, joshuaulrich's quantmod, and quandl-r from quandl. Two of those are general purpose finance packages where FRED access is one feature among many, and the other two are closer competitors. FredR is the closest in shape, being another R binding for the same service. Listing them is a small thing but a useful signal about how the project positions itself, since a package that claimed to be the only way in would not name four. It also means the choice between them is about scope and maintenance rather than about whether an R client for FRED exists.

The README is knitted from README.Rmd and the docs are built by pkgdown

The first line of the README is a warning about editing the wrong file: README.md is generated from README.Rmd, so the R Markdown source is the one to change. A Makefile in the repository root drives the whole documentation chain, and its targets are the map of how the project is assembled:

all: README.md vignettes check docs

README.md: README.Rmd
	$(R) -e "knitr::knit('README.Rmd')"

The vignettes target installs the package with devtools and builds the vignettes from a vignettes/fredr.Rmd. The docs target runs devtools::document() and then pkgdown::build_site(), which is what produces the site at sboysel.github.io/fredr that the README and the get started article point readers to. The check target runs devtools::check(), the standard CRAN submission check. One detail to note before you run any of it: the Makefile hardcodes R=/usr/local/bin/R, so on a machine where R lives elsewhere those targets fail until you edit that line.

CRAN and GitHub install different builds of the same name

Two installation paths are given and they are not interchangeable. The released version comes from CRAN with install.packages("fredr"), which is the path a user with no development setup should take. The development version comes from GitHub with devtools::install_github("sboysel/fredr"), and the example above it has the devtools installation itself commented out, which is a small hint that you are expected to have R and a toolchain already before you go down that path. The repository is a conventional R package rather than a wrapper around something else: DESCRIPTION, NAMESPACE, an R directory, man pages, tests, vignettes, a data directory and _pkgdown.yml for the site, plus a cran-comments.md and a NEWS.md for the changelog. Nothing in the package is fetched at install time, so the install is cheap and the API key remains the only runtime requirement.

Last release in January 2021, last push in April 2023

The activity record is worth weighing before you depend on the package. It is not archived and sits on master, with a last push dated 2023-04-17, but the release history stops earlier: v2.1.0 on 2021-01-31, v2.0.0 on 2020-11-16 and v1.0.0 on 2018-07-28. So the newest tag is more than two years behind the newest commit, which means installing from GitHub and installing from CRAN can give you different code, and a major version bump happened in late 2020 after the first release two years earlier. The licence field records no recognised licence, so check the LICENSE file rather than assuming one from the package metadata. The repository reports 101 stars, 19 forks and 4 open issues, and carries the usual R packaging furniture: a Makefile, .Rbuildignore, sonar-projects.properties, codecov.yml and a contributor code of conduct that contributors agree to by taking part.

Editorial conclusion

fredr is the right choice for an R workflow that needs FRED series and their metadata without leaving the language, and the search-then-fetch pattern is the part worth learning from it. Two limits shape how you use it. Four sources, ICE Libor Rates, ICE Swap Rates and the daily LBMA gold and silver prices, are marked as not permitted for redistribution through the API, so any pipeline that republishes FRED output has to check its series list before it ships. And the package records no recognised licence, with the newest release v2.1.0 dated 2021-01-31 and the last push dated 2023-04-17, so plan for pinning a version and check the FRED API documentation yourself, since the project points you there rather than restating the endpoints.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes