Document possible endpoints from https://research.stlouisfed.org/docs/api/fred/

Hi,

I'm unable to install and load the fredr package in a GitHub Actions job that installs the latest version of R on a machine running the latest version of Ubuntu.

Running install.packages() gives the following error: "ERROR: dependency ‘httr’ is not available for package ‘fredr’"

I've tried installing httr separately, but that doesn't seem to work either.

Here's a link to the latest job fail: https://github.com/gionikola/data-reports/actions/runs/2357378203

Hi! Thank you for this great package.
I was wondering why the limit is capped at 1,000 in the fredr_category_series() function.
I'm trying to access a category with much more items (https://fred.stlouisfed.org/categories/32291)
=> would it be possible to increase the limit to 100k?
Thanks a lot in advance!

GeoFRED is being retired on September 1st, 2022. FRED is replacing this tool with a map feature directly in all series with geographic variable. Would it be possible add a function that downloads the series as a group?
Example- Per Capita Personal Income in Colorado and select 'View Map', then select 'Download as .csv', this contains the relevant data with every state series ID included.

Going through the documentation one last time before submitting to CRAN: verifying parameters are correct, improving function and parameter descriptions, adding usage examples, verifying consistent links and Roxygen syntax, etc.

• Endpoint functions: Categories (Assignee: @sboysel) (#39)
• Endpoint functions: Releases (Assignee: @DavisVaughan) (#43)
• Endpoint functions: Series. To be consistent with the other endpoints, I was considering splitting the functions in R/fredr_series.R into separate files and documentation pages. I think the functions are distinct enough to warrant this and it seems cleaner to me. (Assignee: @sboysel) (#39)
• Endpoint functions: Sources (Assignee: @DavisVaughan) (#45)
• Endpoint functions: Tags (Assignee: @sboysel) (#39)
• Misc functions: fredr_docs(), fredr_set_key(), fredr_endpoints, fredr() (Assignee: @sboysel) (#39)
• README (#39)
• consistent parameter descriptions (i.e. the description for limit might vary more than just the value) (Assignee: @sboysel) (#51)
• consistent parameter ordering across functions (Assignee: @sboysel) (#51)

fredr currently returns only a subset of the response for each category. Metadata from the response ought to be appended to the returned data frame.

Hi, first of all thanks a lot for the amazing package.

I am trying to download the following ticker

but fredr returns me the following response:

> fredr::fredr(series_id = "USD3MTD156N")
Error in (function (endpoint, ..., to_frame = TRUE, print_req = FALSE)  : 
  404: Not Found.  The series does not exist.

How can I check the legitimacy of a series_id?

Is there a variable in the fredr() function that allows you to choose the "Seasonally Adjusted" observation instead of the "Not Seasonally Adjusted"? I have to choose some different variables to get there but would prefer a variable that allows me to choose that.

Hi, Thank you for the time and effort you have put into making this available.
I hope you can shed some light of the following.

Unfortunately my install is failing as follows (system details below):

> devtools::install_github("sboysel/fredr")
Downloading GitHub repo sboysel/fredr@master
from URL https://api.github.com/repos/sboysel/fredr/zipball/master
Installation failed: cannot open file 'C:/Users/<snip>/AppData/Local/Temp/RtmpakieAR/devtools4bec2b7152ce/sboysel-fredr-a506a70/R/fredr.R': No such file or directory
> 

> Sys.info()
                     sysname                      release 
                   "Windows"                      "7 x64" 
                     version                     nodename 
"build 7601, Service Pack 1"               "<snip>" 
                     machine                        login 
                       "x86"                    "<snip>" 
                        user               effective_user 
                   "<snip>"                    "<snip>"

> sessionInfo()
R version 3.4.3 (2017-11-30)
Platform: i386-w64-mingw32/i386 (32-bit)
Running under: Windows 7 x64 (build 7601) Service Pack 1

Matrix products: default

locale:
[1] LC_COLLATE=English_Australia.1252 
[2] LC_CTYPE=English_Australia.1252   
[3] LC_MONETARY=English_Australia.1252
[4] LC_NUMERIC=C                      
[5] LC_TIME=English_Australia.1252    

attached base packages:
[1] stats     graphics  grDevices datasets  utils     methods  
[7] base     

other attached packages:
[1] httr_1.3.1      dplyr_0.7.4     quantmod_0.4-12 TTR_0.23-2     
[5] xts_0.10-0      zoo_1.8-0       here_0.1       

loaded via a namespace (and not attached):
 [1] Rcpp_0.12.14     knitr_1.17       bindr_0.1       
 [4] magrittr_1.5     devtools_1.13.4  lattice_0.20-35 
 [7] R6_2.2.2         rlang_0.1.4      stringr_1.2.0   
[10] tools_3.4.3      grid_3.4.3       packrat_0.4.8-1 
[13] git2r_0.19.0     withr_2.1.0      digest_0.6.12   
[16] yaml_2.1.16      rprojroot_1.2    assertthat_0.2.0
[19] tibble_1.3.4     bindrcpp_0.2     curl_3.1        
[22] memoise_1.1.0    glue_1.2.0       evaluate_0.10.1 
[25] stringi_1.1.6    compiler_3.4.3   backports_1.1.2 
[28] pkgconfig_2.0.1 
> 

Related to #75 - but I didn't want everyone in that thread to get notified.

@sboysel I'd be willing to take another look at this to get this back on CRAN

Honestly I now think the easiest thing to do is to back out your commit with the mocking features. Instead, to keep this on CRAN I would do the following:

1. Skip all tests that require hitting the API if there is no auth token by using a custom skip_if_no_auth() helper in the tests. This would skip tests on CRAN so we never get kicked off again due to spurious failures. I'm pretty sure this is what we were doing before, with the exception of the fredr_docs() one that broke.

2. Nuke appveyor and travis testing and update to github actions

3. Most builds on github actions would run without an auth token. This would mimic running on CRAN.

4. A single build on github actions would run with an auth token, and would run the full test suite. We could set this build up to run on each push to master / pull request, and also add a weekly cron job that would run the test suite just to make sure things are working. Yes this would take awhile, but 1 build is probably okay and it beats the pain of the mocking infrastructure.

5. All examples would be updated from \donttest{} to \dontrun{}. This is what googledrive uses. I'm fairly certain CRAN will sometimes test your examples even if wrapped in \donttest{}. I think \dontrun{} also plays nicely with pkgdown if I'm remembering right, but we would make it so that the examples don't run on pkgdown since they could spuriously fail and break the site.

This is basically the setup that the googledrive package uses, and seems to work fairly well.

This would be a large amount of changes, so if this sounds good to you then I'd like to request that you give me permissions to push to the repo directly (I don't think I have that now)

I was thinking about splitting the vignettes as follows

• Get started: instructs the user how to install, authenticate, and obtain a series
• Categories endpoint functions (we can basically pull examples from the function documentation and annotate)
• Releases endpoint functions
• Series endpoint functions
• Sources endpoint functions
• Tags endpoint functions

This approach has the advantage of familiarizing the user with the returns from each endpoint function in a modular fashion. Thoughts, @DavisVaughan?

Update: Progress is in #47

Prepare for release:

• Check that description is informative
• Check licensing of included files
• devtools::build_readme()
• usethis::use_cran_comments()
• devtools::check(remote = TRUE, manual = TRUE)
• devtools::check_win_devel()
• rhub::check_for_cran()
• Update cran-comments.md
• Review pkgdown reference index for, e.g., missing topics

Submit to CRAN:

• usethis::use_version('major')
• devtools::submit_cran()
• Approve email

Wait for CRAN...

• Accepted 🎉
• usethis::use_github_release()
• usethis::use_dev_version()
• Tweet

It would be nice if fredr_series_observations (or potentially all fredr* functions) could accept multiple series IDs. For the time being, this behavior can be achieved by mapping fredr_series_observations over a vector of IDs:

library(tidyverse)

multiple_series_ids <- c("GNPCA", "GNP", "FEDFUNDS")
names(multiple_series_ids) <- multiple_series_ids

purrr::map_dfr(
  .x = multiple_series_ids,
  .f = function(x) fredr_series_observations(series_id = x) %>%
    dplyr::rename(value = x),
  .id = "series_id"
)

https://github.com/r-lib/pkgdown

Greetings Sam,

Thank you for creating this package, it's been very helpful. I appreciate the vast selection of functions allowing one to search from categories to series, or get the tags for a series - it's very useful!

I am going to describe my current approach and process, then pose my question. I'm going to include a fair amount of detail, in the change that it's helpful to others. I am new to API use and the fredr package, so it may be that there is a much more succinct way to accomplish this. If that's the case, I'd be happy to learn how to navigate my interactions with the FRED API more efficiently.

So here we go, I've been looking to capture all macroeconomic variables related to the USA, with some additional filters (monthly reporting, at least 8 years of observations, and not discontinued). Ultimately I'm looking to capture as many variables as are relevant and then select the relevant ones using my modeling approach.

Most of the series selection processes I've observed are great for selecting one or two indicators. If one knows exactly what they're looking for, the interface is perfect. However, it was less clear to me what one should do to cast a wide net and get all variables of interest.

So, I learned that the structure of the FRED data starts with category IDs. Category IDs may have child category IDs. For example 'Business' could be the parent category to 'Small Business'. Category IDs will either have child category IDs or series underneath them. In our business example, a series under 'small business' could be 'number of employees'.

Wanting to capture as many relevant series as possible, started at the parent category ID (0) and iterated down each chain of category IDs until I got a master list of all category IDs. Then I iterated through the category IDs and captured the series IDs for all series meeting my search criteria. Now I am looking to iterate across the series and build a data frame with all of the results.

My question: is there a way to query all (or multiple) series in one request so I'm not pinging the FRED API many many times?

I'd also like to note one functionality that I think would be really useful. From my understanding 'tag_names'' in the fredr_category_series() function requires that the category search produces only the series meeting all the tag criteria. So if I wanted to find results for 'farm', 'house', and 'usa' and I wrote a search using 'farm;house;usa' then I would only return results which included all of those tags (probably almost no results). It'd be great to have the optionality to find series meeting any of those criteria.

Sincerely,
Justin

For fredr_series returns.

See business-science/tibbletime. Would reintroduce to some heavier dependencies.

Should probably change the function altogether so that it doesn't modify Renviron at all. See @DavisVaughan's suggestion in #13

When the documentation is more or less stable:

https://pkgdown.r-lib.org/articles/pkgdown.html#search

Given the way we've change the API over the last few weeks, I think 1.0.0 is appropriate for the initial CRAN release. Just wanted to get your thoughts, @DavisVaughan

From https://cran.r-project.org/web/packages/fredr/fredr.pdf under fred_series_observations:

However, it appears that fredr cannot accept more than one date for parameter vintage_dates:

Ideally, when passing multiple dates to vintage_dates, a fourth column in the return tibble called, for example, vintage_date would denote which vintage that data point is from.

Hi! I'm having an issue when I try to download multiple series.

The following error appears:

Request failed [504]. Retrying in 1.7 seconds...
Request failed [504]. Retrying in 1.8 seconds...
Error: 404: Not Found. The series does not exist.
Call rlang::last_error() to see a backtrace

I'm using this code to download multiple series:

fredr_set_key("9a0529b046b504306865a494d1ce7a6b")

params <- list(
series_id = c("ICSA", "IC4WSA","PAYEMS", "NPPTTL", "UNRATE", "LNS12032194", "LNS13023706", "LNS12032194",
"AWHAETP", "CEU3000000002", "CSUSHPINSA", "PERMIT", "HOUST", "HOUST1F", "HOUST5F", "HSN1F",
"EXHOSLUSM495S", "NHSDPTS", "MORTGAGE30US", "MRTSSM44X72USS", "RSFSXMV","ECOMSA", "UMCSENT", "PSAVERT", "HNONWPDPI",
"TOTALSA", "INDPRO", "IPMAN", "DGORDER", "NEWORDER", "CEFDFSA066MSFRBPHI", "ISRATIO", "BOPTEXP",
"BOPTIMP", "TWEXB", "CPROFIT", "PNFI", "PPIACO", "PCUOMFGOMFG", "CPILFESL", "PCEPI", "PCEPILFE",
"PCETRIM1M158SFRBDAL", "T5YIFR", "CES0500000003", "IREXFUELS", "W875RX1", "PCE", "SP500", "CPIAUCSL",
"USD3MTD156N", "FEDFUNDS", "GDPC1", "PCEC96", "FPIC1", "EXPGSC1", "IMPGSC1", "GCEC1", "A261RX1Q020SBEA"),
frequency = c("m", "m","m", "m", "m", "m", "m", "m",
"m", "m", "m", "m", "m", "m", "m", "m",
"m", "m", "m", "m", "m", "q", "m", "m","q",
"m", "m", "m", "m", "m", "m", "m", "m",
"m", "m", "q", "q", "m", "m", "m", "m", "m",
"m", "m", "m", "m", "m", "m", "m", "m",
"m", "m", "q", "q", "q", "q", "q", "q", "q")
)

fred.data <- pmap_dfr(
.l= params,
.f = ~ fredr(series_id = .x, frequency = .y))

I just installed fredr, and I have an API key. Any call to fredr results in the message
'enquos' is not an exported object from 'namespace:rlang'
I've tried in clean sessions with no change. Any suggestions?

`
R version 3.3.2 (2016-10-31)
Platform: x86_64-apple-darwin13.4.0 (64-bit)
Running under: macOS 10.13.6

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats graphics grDevices utils datasets methods base

other attached packages:
[1] fredr_1.0.0 forcats_0.2.0 stringr_1.2.0 dplyr_0.7.4 purrr_0.2.4 readr_1.1.1 tidyr_0.7.2 tibble_1.3.4
[9] ggplot2_2.2.1 tidyverse_1.2.1 kmgCode_0.1.0 Quandl_2.8.0 xts_0.9-7 zoo_1.7-14

loaded via a namespace (and not attached):
[1] Rcpp_0.12.14 lubridate_1.7.1 lattice_0.20-34 png_0.1-7
[5] sysfonts_0.5 assertthat_0.2.0 psych_1.7.3.21 R6_2.2.2
[9] cellranger_1.1.0 plyr_1.8.4 httr_1.3.1 rlang_0.1.4
[13] lazyeval_0.2.0 curl_3.0 readxl_1.0.0 rstudioapi_0.7
[17] extrafontdb_1.0 TTR_0.23-1 tidyquant_0.5.3 extrafont_0.17
[21] foreign_0.8-67 munsell_0.4.3 broom_0.4.2 modelr_0.1.1
[25] pkgconfig_2.0.1 mnormt_1.5-5 gridExtra_2.3 crayon_1.3.4
[29] showtextdb_1.0 grid_3.3.2 nlme_3.1-128 jsonlite_1.5
[33] Rttf2pt1_1.3.4 gtable_0.2.0 DBI_0.7 magrittr_1.5
[37] scales_0.5.0 PerformanceAnalytics_1.4.3541 quantmod_0.4-11 cli_1.0.0
[41] stringi_1.1.6 reshape2_1.4.3 ggthemes_3.4.0 bindrcpp_0.2
[45] xml2_1.1.1 tools_3.3.2 showtext_0.4-6 glue_1.1.1
[49] hms_0.3 parallel_3.3.2 yaml_2.1.14 colorspace_1.3-2
[53] rvest_0.3.2 bindr_0.1 haven_1.1.0
`

I have the Ubuntu Focal default R (3.6.3) installed on my server, with RStudio Server running. I am running fredr 2.1.0.

Running the following minimal R script:

library(fredr)
fredr_set_key(api_key_fred)
foo <- fredr(series_id = "SP500")

Yields the following error:

foo <- fredr(series_id = "SP500")
Error: :
Run rlang::last_error() to see where the error occurred.
rlang::last_error()
<error/rlang_error>
:
Backtrace:

1. fredr::fredr(series_id = "SP500")
   Run rlang::last_trace() to see the full context.

rlang::last_trace()
<error/rlang_error>
:
Backtrace:
█

1. └─fredr::fredr(series_id = "SP500")
2. ├─base::do.call(fredr_request, c(fredr_args, user_args))
3. └─(function (endpoint, ..., to_frame = TRUE, print_req = FALSE, ...

Let me know if there's any other info I can give you.

I was thinking about splitting the vignettes as follows

• Get started: instructs the user how to install, authenticate, and obtain a series
• Categories endpoint functions (we can basically pull examples from the function documentation and annotate)
• Releases endpoint functions
• Series endpoint functions
• Sources endpoint functions
• Tags endpoint functions

This approach has the advantage of familiarizing the user with the returns from each endpoint function in a modular fashion.

https://research.stlouisfed.org/docs/api/fred/#Series

The following endpoints need to be implemented properly and consistently in fredr:

• fredr_series() - Get an economic data series. (#30)
• fredr_series_categories() - Get the categories for an economic data series. (#30)
• fredr_series_observations() - Get the observations or data values for an economic data series. (#28)
• fredr_series_release() - Get the release for an economic data series. (#30)
• fredr_series_search() - Get economic data series that match keywords. (#28)
• fredr_series_search_tags() - Get the tags for a series search. (#28)
• fredr_series_search_related_tags() - Get the related tags for a series search. (#28)
• fredr_series_tags() - Get the tags for an economic data series. (#30)
• fredr_series_updates() - Get economic data series sorted by when observations were updated on the FRED® server. (#30)
• fredr_series_vintagedates() - Get the dates in history when a series' data values were revised or new data values were released. (#30)

The functions are to be implemented with explicit arguments for each parameter in the FRED API (see documentation for each endpoint and the discussion in #20).

Package was dropped from CRAN today due to some outstanding issues. The CRAN check results are no longer available either. travis build have been failing so it could be related. Will look into it this week to get it accepted again.

I had some categories I had picked out manually from some lists that FRED had published and I was comparing them against what I downloaded and noticed they weren't in any of the lists that fredr downloads. So i looked into the api calls and it looks like the API stops at 1000 returns

for example

fredr_series_categories("UMCSENT")
is part of 32457 but you won't see if when you do a

fredr_category_series(32457)$id

so far I've checked some others and it appears when implementing the calls they stop at 1000

I don't know how to solve this nor where to go to get all the entries per series. Another series that has a similar problem is 97 (housing)

We've talked about the fact that fredr_series_observations() is likely going to be the most popular function of the package, but is also annoying to type. What if, since it really is the function in the package, we aliased it with fredr() (we would keep both and they could share a Rd file)?

We'd have to go back and replace the current fredr() function with something like fredr_request(), but that wouldn't be the end of the world.

Feel free to disagree! Just an idea

As of now, unit testing is quite haphazard. I'd like to establish a consistent set of tests for each function.

1. fredr_set_key() - fine as is
2. fredr()
   • errors when API key is not set
   • errors for bad endpoint
   • errors for non-200 HTTP response
   • return should always be a tibble.
3. Endpoint functions wrapped around fredr()
   • errors for bad parameter names and values**
   • return should always be a tibble.

Note that the FRED API will return

• a 404 error if the request URL is not found (e.g. bad endpoint passed to fredr())
• a 400 if the endpoint is value but the request is improperly formed (e.g. bad parameters passed to fredr() or the endpoint functions).

Some initial testing suggests the FRED API 400 codes return useful error messages for bad values and that improperly named parameters are simply ignored (explicitly defined parameters would solve this anyways).

** @DavisVaughan What would you consider best practice for errors in an API package: check that parameter value types are proper before sending the request or allow the API to return an error?

perhaps use do.call and rbind instead

https://research.stlouisfed.org/docs/api/fred/#Categories

The following endpoints need to be implemented properly and consistently in fredr:

• fredr_category() - Get a category. (#37)
• fredr_category_children() - Get the child categories for a specified parent category. (#37)
• fredr_category_related() - Get the related categories for a category. (#37)
• fredr_category_series() - Get the series in a category. (#37)
• fredr_category_tags() - Get the tags for a category. (#37)
• fredr_category_related_tags() - Get the related tags for a category. (#37)

The functions are to be implemented with explicit arguments for each parameter in the FRED API (see documentation for each endpoint and the discussion in #20).

Hi,
In recent days I have been experiencing a new error with fredr_series_observations while fetching data from FRED, as R throws the following error

No encoding supplied: defaulting to UTF-8.
Error in (function (endpoint, ..., to_frame = TRUE, print_req = FALSE)  : 
  : 

Until last week all was working smoothly. What is a bit strange is that it appears to be totally unpredictable: if I call the fredr_series_observations function from a script with source or running the code line-by-line it makes little difference. Any hint?
Thanks!

I'm going to work on this a bit tonight for the current implemented functions. Should be easy to then extend it.

This would at least tidy up the top level result. children are already coerced to data frames as well.

ex <- fredr::fredr_release_tables(release_id = 53L, element_id = 12886)

ex
#> $name
#> [1] "Personal consumption expenditures"
#> 
#> $element_id
#> [1] 12886
#> 
#> $release_id
#> [1] "53"
#> 
#> $elements
#> $elements$`12887`
#> $elements$`12887`$element_id
#> [1] 12887
#> 
#> $elements$`12887`$release_id
#> [1] 53
#> 
#> $elements$`12887`$series_id
#> [1] "DGDSRL1A225NBEA"
#> 
#> $elements$`12887`$parent_id
#> [1] 12886
#> 
#> $elements$`12887`$line
#> [1] "3"
#> 
#> $elements$`12887`$type
#> [1] "series"
#> 
#> $elements$`12887`$name
#> [1] "Goods"
#> 
#> $elements$`12887`$level
#> [1] "1"
#> 
#> $elements$`12887`$children
#>   element_id release_id       series_id parent_id line   type
#> 1      12888         53 DDURRL1A225NBEA     12887    4 series
#> 2      12889         53 DNDGRL1A225NBEA     12887    5 series
#>               name level children
#> 1    Durable goods     2     NULL
#> 2 Nondurable goods     2     NULL
#> 
#> 
#> $elements$`12888`
#> $elements$`12888`$element_id
#> [1] 12888
#> 
#> $elements$`12888`$release_id
#> [1] 53
#> 
#> $elements$`12888`$series_id
#> [1] "DDURRL1A225NBEA"
#> 
#> $elements$`12888`$parent_id
#> [1] 12887
#> 
#> $elements$`12888`$line
#> [1] "4"
#> 
#> $elements$`12888`$type
#> [1] "series"
#> 
#> $elements$`12888`$name
#> [1] "Durable goods"
#> 
#> $elements$`12888`$level
#> [1] "2"
#> 
#> $elements$`12888`$children
#> list()
#> 
#> 
#> $elements$`12889`
#> $elements$`12889`$element_id
#> [1] 12889
#> 
#> $elements$`12889`$release_id
#> [1] 53
#> 
#> $elements$`12889`$series_id
#> [1] "DNDGRL1A225NBEA"
#> 
#> $elements$`12889`$parent_id
#> [1] 12887
#> 
#> $elements$`12889`$line
#> [1] "5"
#> 
#> $elements$`12889`$type
#> [1] "series"
#> 
#> $elements$`12889`$name
#> [1] "Nondurable goods"
#> 
#> $elements$`12889`$level
#> [1] "2"
#> 
#> $elements$`12889`$children
#> list()
#> 
#> 
#> $elements$`12890`
#> $elements$`12890`$element_id
#> [1] 12890
#> 
#> $elements$`12890`$release_id
#> [1] 53
#> 
#> $elements$`12890`$series_id
#> [1] "DSERRL1A225NBEA"
#> 
#> $elements$`12890`$parent_id
#> [1] 12886
#> 
#> $elements$`12890`$line
#> [1] "6"
#> 
#> $elements$`12890`$type
#> [1] "series"
#> 
#> $elements$`12890`$name
#> [1] "Services"
#> 
#> $elements$`12890`$level
#> [1] "1"
#> 
#> $elements$`12890`$children
#> list()

ex_tidy <- tibble::enframe(ex$elements)

ex_tidy
#> # A tibble: 4 x 2
#>   name  value     
#>   <chr> <list>    
#> 1 12887 <list [9]>
#> 2 12888 <list [9]>
#> 3 12889 <list [9]>
#> 4 12890 <list [9]>

ex_tidy$value[[1]]
#> $element_id
#> [1] 12887
#> 
#> $release_id
#> [1] 53
#> 
#> $series_id
#> [1] "DGDSRL1A225NBEA"
#> 
#> $parent_id
#> [1] 12886
#> 
#> $line
#> [1] "3"
#> 
#> $type
#> [1] "series"
#> 
#> $name
#> [1] "Goods"
#> 
#> $level
#> [1] "1"
#> 
#> $children
#>   element_id release_id       series_id parent_id line   type
#> 1      12888         53 DDURRL1A225NBEA     12887    4 series
#> 2      12889         53 DNDGRL1A225NBEA     12887    5 series
#>               name level children
#> 1    Durable goods     2     NULL
#> 2 Nondurable goods     2     NULL

Created on 2018-07-17 by the reprex package (v0.2.0).

Hey! Just curious why this was recently pulled from the CRAN repo? I downloaded the devtools version but was curious what happened. Let me know, seems like a great package!

I would love to see this package on CRAN. I was just about to write an interface to FRED that does more than what we do in tidyquant (like accessing all the params of the API) when I discovered this. I think it has great potential!

If you don't mind, I'd like to suggest a few features that I personally would like. I'm hardcore biased towards tidyverse, so take it with a grain of salt.

• Allow fredr_series to return multiple series in 1 call. Under the hood it could call map() to make multiple calls to the API, but it would be nice as a user facing feature to let us input a vector of series ids.

• With regards to the above, it would then make sense to change from returning xts to returning a tibble. This could have a column, id that contained the series_id and you could stack series together into 1 tidy data frame. It would be up to the user to ensure that each series allowed for the specified frequency and other params, or those could be vectorized as well.

• I'm not sure the fredr_key() function is working perfectly. I was not in an RStudio project, and tried to set it for the first time with fredr_key("my_key") and it errored out because I already had an .Renviron file. In riingo I let the user set the key temporarily with riingo_set_token() which sets an option() or they can set it permanently themselves by modifying their .Renviron file. This way I'm not directly messing with their .Renvion file.

• The FRED API has a lot of useful endpoints. Would it make sense to expose all of them through something like fredr_series(), fredr_series_observations(), fredr_series_release(), ... and so on for series and for tags and everything else? It would work well with tab completion.

• Lastly, I think the FRED API is relatively stable in terms of parameters that get passed through. To be easier on the user, maybe you could provide things such as series_id, observation_start, and all the other api params as function params for each of the above suggested endpoints. With roxygen2 and @inheritParams, it would really only be a matter of documenting them once, and sharing them across all functions that used them, so probably not too much work. This would be nice as it could keep the user from having to even go to the API docs for more info.

Hi! I have been using fredr for my research, but recently I have noticed that some imported series do not display correct start and end dates when compared with dates on Fred website. To give an example:

df <- fredr_series(series_id='FGCCSAQ027S', frequency='q')

is a series from 1945-10-01 to 2016-10-01 (or, in quarters, 1945Q4 - 2016Q4). Once it is imported, regardless of the specific format (I use both ts and xts), R shows that it starts in 1947Q2 and ends in 2018Q2.
This issue, nevertheless, is not present in all series. For instance, when I run the same code for another series
df.xts <- as.xts(fredr_series(series_id='FDHBFRBN', frequency='q'))

beginnings and ends match as usual. Any explanation for this behaviour?

https://research.stlouisfed.org/docs/api/fred/#Tags

The following endpoints need to be implemented properly and consistently in fredr:

• fredr_tags() - Get all tags, search for tags, or get tags by name. (#28)
• fredr_related_tags() - Get the related tags for one or more tags.
• fredr_tags_series() - Get the series matching tags.

The functions are to be implemented with explicit arguments for each parameter in the FRED API (see documentation for each endpoint and the discussion in #20).

Prepare for release:

• devtools::build_readme()
• Check current CRAN check results
• devtools::check(remote = TRUE, manual = TRUE)
• devtools::check_win_devel()
• rhub::check_for_cran()
• revdepcheck::revdep_check(num_workers = 4)
• Update cran-comments.md
• Polish NEWS
• Review pkgdown reference index for, e.g., missing topics

Submit to CRAN:

• usethis::use_version('minor')
• devtools::submit_cran()
• Approve email

Wait for CRAN...

• Accepted 🎉
• usethis::use_github_release()
• usethis::use_dev_version()
• Finish blog post
• Tweet
• Add link to blog post in pkgdown news menu

similar to traverseCategories found here?

https://github.com/jcizel/FredR/blob/master/R/FredR.R

I'm having a hard time exploring all the categories. I have to sift through them manually and what I'd like to do is start at a base node up top and sort all the way down by popularity but I need to be able to traverse the tree first.

https://research.stlouisfed.org/docs/api/fred/#Sources

The following endpoints need to be implemented properly and consistently in fredr:

• fredr_sources() - Get all sources of economic data. (#34)
• fredr_source() - Get a source of economic data. (#34)
• fredr_source_releases() - Get the releases for a source. (#34)

The functions are to be implemented with explicit arguments for each parameter in the FRED API (see documentation for each endpoint and the discussion in #20).

In your example use of

federal_funds_series <- fredr_series_search_text(
search_text = "federal funds",
order_by = "popularity",
sort_order = "desc",
limit = 1
)

popular_funds_series <- federal_funds_series$id

you end up with M2 not FedFunds

Is it possible to pull more than 1000 records with fredr_search() ?

https://research.stlouisfed.org/docs/api/fred/#Releases

The following endpoints need to be implemented properly and consistently in fredr:

• fredr_releases() - Get all releases of economic data. (#33 )
• fredr_releases_dates()- Get release dates for all releases of economic data. (#33)
• fredr_release() - Get a release of economic data. (#33)
• fredr_release_dates() - Get release dates for a release of economic data. (#33)
• fredr_release_series() - Get the series on a release of economic data. (#33)
• fredr_release_sources() - Get the sources for a release of economic data. (#33)
• fredr_release_tags() - Get the tags for a release. (#33)
• fredr_release_related_tags() - Get the related tags for a release. (#33)
• fredr_release_tables()- Get the release tables for a given release. (#33)

The functions are to be implemented with explicit arguments for each parameter in the FRED API (see documentation for each endpoint and the discussion in #20).

Following up on the discussion in #72 . Running the full test suite leads to the package build time running in excess of 20 mins, mostly due to latency and/or connection issues with the FRED server. Using a more elegant web testing framework such as nealrichardson/httptest would handle test calls more efficiently.

Before sending to CRAN, ensure that this is updated to say "Install from CRAN using..." and then remove the section that says you can "only install from github". Do this post merging #55 to reduce merge conflicts

Hi Given the problems installing reported in issue #3, I tried to install from an archive. R requires tar.gz files.

Further when I tried to unpack the .zip archive to create the tar.gz myself winzip remports the zip file is corrupt. I've tried several downloads.

Hope that helps.

Had the need recently to use something like this

library(fredr)
library(tidyverse)
fredr_paginate <- function(fredr, ..., sleep = 0L, verbose = FALSE) {
  
  stopifnot(inherits(fredr, "function"))
  stopifnot(length(sleep) == 1, is.numeric(sleep))
  
  args <- list(...)
  stopifnot(!"offset" %in% names(args))
  
  # iteration setup
  done <- FALSE
  offset <- 0L
  if (!"limit" %in% names(args)) {
    limit <- 1000L
  }
  results_list <- list()
  
  # iterate
  while (!done) {
    
    # set offset parameter
    args[["offset"]] <- offset * limit
    
    if (verbose) {
      message(paste("Offset:", args[["offset"]]))
    }
    
    # get page
    results <- do.call(what = fredr, args = args)
    
    # add page to page list
    results_list[[offset + 1]] <- results
    
    # done if results returned are less than limit parameter
    if (nrow(results) < limit) {
      done <- TRUE
    }
    
    # increment offset
    offset <- offset + 1
    
    # pause before iterating again
    Sys.sleep(sleep)
    
  }
  
  # return results
  results_list
  
}

series_list <- fredr_paginate(fredr_series_search_text, search_text = "Mean Commute Time", verbose = TRUE)
#> Offset: 0
#> Offset: 1000
#> Offset: 2000
#> Offset: 3000
series <- dplyr::bind_rows(series_list)
series
#> # A tibble: 3,143 x 16
#>    id    realtime_start realtime_end title observation_sta… observation_end
#>    <chr> <chr>          <chr>        <chr> <chr>            <chr>          
#>  1 B080… 2018-10-03     2018-10-03   Mean… 2009-01-01       2016-01-01     
#>  2 B080… 2018-10-03     2018-10-03   Mean… 2009-01-01       2016-01-01     
#>  3 B080… 2018-10-03     2018-10-03   Mean… 2009-01-01       2016-01-01     
#>  4 B080… 2018-10-03     2018-10-03   Mean… 2009-01-01       2016-01-01     
#>  5 B080… 2018-10-03     2018-10-03   Mean… 2009-01-01       2016-01-01     
#>  6 B080… 2018-10-03     2018-10-03   Mean… 2009-01-01       2016-01-01     
#>  7 B080… 2018-10-03     2018-10-03   Mean… 2009-01-01       2016-01-01     
#>  8 B080… 2018-10-03     2018-10-03   Mean… 2009-01-01       2016-01-01     
#>  9 B080… 2018-10-03     2018-10-03   Mean… 2009-01-01       2016-01-01     
#> 10 B080… 2018-10-03     2018-10-03   Mean… 2009-01-01       2016-01-01     
#> # ... with 3,133 more rows, and 10 more variables: frequency <chr>,
#> #   frequency_short <chr>, units <chr>, units_short <chr>,
#> #   seasonal_adjustment <chr>, seasonal_adjustment_short <chr>,
#> #   last_updated <chr>, popularity <int>, group_popularity <int>,
#> #   notes <chr>

^{Created on 2018-10-03 by the reprex package (v0.2.1)}

I'm quite ignorant of best practices regarding these types of functions so any input would be appreciated.