Manual exports are useful for learning, but many routine workflows benefit from automated export. The REDCap application programming interface, or API, allows approved users and scripts to request data directly from a REDCap project. In R, an API workflow can reduce repetitive manual downloading, ensure that the same export options are used each time, and support scheduled data quality reporting. However, API use introduces security and governance responsibilities. API tokens grant access to project data and must be protected carefully (Harris et al., 2009, 2019; Republic of Kenya, 2019).
An API token is a credential. It should be treated like a password. It should not be written directly into a script that is shared by email, uploaded to a public repository, or included in course materials with real data. A safer approach is to store sensitive values in environment variables or a local .Renviron file that is not committed to version control. The script can then read the token at runtime without exposing it in the code.
The following is a conceptual example. It is included to teach workflow structure, not to encourage learners to paste real credentials into scripts:

library(httr2)
library(tidyverse)
library(janitor)
redcap_url <- “https://redcap.example.org/api/”
redcap_token <- Sys.getenv(“REDCAP_API_TOKEN”)
response <- request(redcap_url) |>
req_body_form(
token = redcap_token,
content = “record”,
format = “csv”,
type = “flat”
) |>
req_perform()
raw_records <- response |>
resp_body_string() |>
read_csv() |>
clean_names()

The script defines the REDCap API URL, reads the token from an environment variable, requests records in CSV format, converts the response body into a string, reads it as CSV, and standardizes column names. In a real implementation, the script should include error handling, logging, access control, and review by someone who understands the REDCap project configuration. The study team should also define whether API exports include all records, selected instruments, selected events, or only de-identified fields.
API exports should be governed by the same principles as manual exports. The team should know who has API access, what data can be exported, where the export is stored, whether identifiers are included, and whether the transfer is secure. If the dataset contains personal or sensitive health information, data protection requirements apply. In Kenya, clinical research teams must consider the Data Protection Act and institutional governance policies when handling personal data (Republic of Kenya, 2019). Similar obligations exist in many jurisdictions.
The API is powerful because it allows workflows to be automated, but automation should be designed carefully. A poorly designed script can repeatedly export identifiable data to an insecure location. A token placed in an uncontrolled script can expose an entire project. A scheduled job can produce outdated or misleading reports if export settings are wrong. Therefore, API workflows should be documented, tested, and approved before they become routine operational tools.