This release of redquack is bittersweet for me. I started a new job, which means I can no longer access a large REDCap project at the University of Pittsburgh—the very one I used to create the package. I’m on the hunt at the University of Wisconsin-Madison for large REDCap projects that could benefit from redquack. In the meantime, the development of redquack will likely stall as I try to grow a community of users.
That said, I’m excited to share what’s new in redquack 0.3.0. This release includes a complete interface redesign that makes working with REDCap data feel more natural and tidyverse-friendly.

What’s New in 0.3.0
A Complete Interface Redesign
The biggest change in this release is a ground-up redesign of how you interact with your REDCap data. Instead of wrestling with low-level database operations, you now have a suite of convenience functions that make the workflow feel seamless.
Here’s what a typical workflow looks like now:
library(redquack)
library(dplyr)
# Create a duckdb connection
conn <- use_duckdb()
# Transfer your redcap data
redcap_to_db(
conn,
url = "https://your-redcap-instance.edu/api/",
token = keyring::key_get("redcap", "large_project")
)
# Work with your data using familiar dplyr syntax
data <- tbl_redcap(conn) |>
filter(variable == 1) |>
collect_labeled()
# When you're done
close_duckdb(conn)Convenience Functions
The redesign introduces several new functions that handle common tasks:
use_duckdb()andclose_duckdb()for clean connection managementtbl_redcap()creates table references that work seamlessly with dplyr verbscollect_labeled()andcollect_labeled_list()apply REDCap labels and convert coded values on-the-flycollect_list()splits data into instrument-specific tableslist_to_env()loads instruments directly into your global environmentsave_parquet()for efficient data export when you need to share files
These functions eliminate the need to remember table names or manually apply labels—the package handles all of that for you.
Labeling Control
The new collect_labeled() function gives you control over how REDCap labels and coded values are applied—something that no other package has to offer:
# Full labeling and conversion (default)
data <- tbl_redcap(conn) |> collect_labeled()
# Keep raw coded values
data <- tbl_redcap(conn) |> collect_labeled(convert = FALSE)
# Column labels only
data <- tbl_redcap(conn) |> collect_labeled(vals = FALSE)
# Value conversion only
data <- tbl_redcap(conn) |> collect_labeled(cols = FALSE)REDCap Audit Logs
You can now pull REDCap audit logs directly into your database with configurable date ranges (the default is 7 days to handle large projects):
# Get logs from the past week (default)
logs <- redcap_log(conn)
# Or specify a custom date range in redcap_to_db()
redcap_to_db(
conn,
url = "https://your-redcap-instance.edu/api/",
token = keyring::key_get("redcap", "your_project"),
redcap_log_begin_date = "2025-01-01",
redcap_log_end_date = "2025-06-30"
)Breaking Changes
This redesign does introduce some breaking changes—mostly parameter renames for consistency:
logs()is nowtransfer_log()redcap_uriis nowurlinredcap_to_db()verboseis nowechowith options: “all”, “progress”, or “none”- Data export formatting parameters (
raw_or_label, etc.) have been removed since labeling is now handled by collection functions
Check the package website for complete migration guidance.
Installation
Install from CRAN:
pak::pak("redquack")Or get the latest development version:
pak::pak("dylanpieper/redquack")Looking Forward
This release represents a major step toward making redquack feel like a natural extension of the tidyverse. I’m hopeful that the cleaner interface will make it easier for researchers to adopt, especially those working with large REDCap projects that push the limits of traditional extraction methods.
If you’re using redquack or have a massive REDCap database that could benefit from it, I’d love to hear from you (dylanpieper@gmail.com or submit a GitHub issue). Building a community around this package is the best way to ensure it continues to evolve and improve.