Creates an object of class redcapApiConnection for
using the REDCap API
redcapConnection(
url = getOption("redcap_api_url"),
token,
config = httr::config(),
retries = 5,
retry_interval = 2^(seq_len(retries)),
retry_quietly = TRUE
)# S3 method for redcapApiConnection
print(x, ...)
offlineConnection(
meta_data = NULL,
arms = NULL,
events = NULL,
instruments = NULL,
field_names = NULL,
mapping = NULL,
users = NULL,
version = NULL,
project_info = NULL,
file_repo = NULL,
repeat_instrument = NULL,
records = NULL
)
# S3 method for redcapOfflineConnection
print(x, ...)
URL for a REDCap database API. Check your institution's REDCap
documentation for this address. Either url or conn must
be specified.
REDCap API token
A list to be passed to httr::POST. This allows the
user to set additional configurations for the API calls, such as
certificates, ssl version, etc. For the majority of users, this does
not need to be altered. See Details for more about this argument's
purpose and the redcapAPI wiki for specifics on its use.
integerish(1). Sets the number of attempts to make to the
API if a timeout error is encountered. Must be a positive value.
numeric. Sets the intervals (in seconds) at
which retries are attempted. By default, set at a 2^r where
r is the rth retry (ie, 2, 4, 8, 16, ...). For fixed
intervals, provide a single value. Values will be recycled to match
the number of retries.
logical(1). When FALSE, messages will
be shown giving the status of the API calls. Defaults to TRUE.
redcapConnection object to be printed
arguments to pass to other methods
Either a character giving the file from which the
metadata can be read, or a data.frame.
Either a character giving the file from which the
arms can be read, or a data.frame.
Either a character giving the file from which the
events can be read, or a data.frame.
Either a character giving the file from which the
instruments can be read, or a data.frame.
Either a character giving the file from which the
field names can be read, or a data.frame.
Either a character giving the file from which the
Event Instrument mappings can be read, or a data.frame.
Either a character giving the file from which the
User settings can be read, or a data.frame.
Either a character giving the file from which the
version can be read, or a data.frame.
Either a character giving the file from which the
Project Information can be read, or a data.frame.
Either a character giving the file from which the
File Repository Listing can be read, or a data.frame.
Either a character giving the file from which the
Repeating Instruments and Events settings can be read, or a data.frame.
Note: The REDCap GUI doesn't offer a download file of these settings
(at the time of this writing).
Either a character giving the file from which the
Records can be read, or a data.frame. This should be the raw
data as downloaded from the API, for instance. Using labelled or formatted
data is likely to result in errors when passed to other functions.
Jeffrey Horner
redcapConnection objects will retrieve and cache various forms of
project information. This can make metadata, arms, events, instruments, fieldnames,
arm-event mappings, users, version, project information, and fileRepository available
directly from the redcapConnection object. Take note that
the retrieval of these objects uses the default values of the respective
export functions (excepting the file repository,
which uses recursive = TRUE).
For each of these objects, there are four methods that can be called from
the redcapConnection object: the get method (called via
rcon$metadata(), for example); the has method (rcon$has_metadata),
which returns a logical indicating if the metadata has been cached;
the flush method (rcon$flush_metadata), which removes the cached value;
and the refresh method (rcon$refresh_metadata), which replaces the
current value with a new call to the API. There is also a flush_all
and refresh_all method.
The redcapConnection object also stores the user preferences for
handling repeated attempts to call the API. In the event of a timeout
error or server unavailability, these settings allow a system pause before
attempting another API call. In the event all of the retries fail, the
error message of the last attempt will be returned. These settings may
be altered at any time using the methods rcon$set_retries(r),
rcon$set_retry_interval(ri), and rcon$set_retry_quietly(rq).
The argument to these functions have the same requirements as the
corresponding arguments to redcapConnection.
For convenience, you may consider using
options(redcap_api_url=[your URL here]) in your RProfile.
To obtain an API token for a project, do the following:
Enter the 'User Rights' section of a project
Select a user
Check the box for 'API Data Export' or 'API Data Import,' as appropriate. A full tutorial on
configuring REDCap to use the API can be found at https://github.com/vubiostat/redcapAPI/wiki
Tokens are specific to a project, and a token must be created for each project for which you wish to use the API.
The config argument is passed to the httr::POST argument of
the same name. The most likely reason for using this argument is that the
certificate files bundled in httr have fallen out of date.
Hadley Wickham is pretty good about keeping those certificates up
to date, so most of the time this problem can be resolved by updating
httr to the most recent version. If that doesn't work, a
certificate file can be manually passed via the config argument.
The redcapAPI wiki has a more detailed tutorial on how to
find and pass an SSL certificate to the API call
(https://github.com/vubiostat/redcapAPI/wiki/Manually-Setting-an-SSL-Certificate-File).
Additional Curl option can be set in the config argument. See the documentation
for httr::config and httr:httr_options for more Curl options.