Introduction
Research Data Management (RDM) is in constant development; more and larger datasets are being generated and analyzed, research is more collaborative (Parish, Boyack, and Ioannidis 2018), and funders require increasingly FAIR (Wilkinson et al. 2016) and open data (Perrier et al. 2017) in an effort to increase data quality, integrity, reproducibility, and reusability. In response, many scientific communities have agreed on, or are working towards reporting standards and frameworks for research output. These standards include guidelines for metadata on sample collection, storage conditions, and measurement details (Athar et al. 2019; Barrett et al. 2012; Deutsch et al. 2023; Kopczynski et al. 2024; Perez-Riverol et al. 2025; wwPDB consortium et al. 2019; Yurekten et al. 2024) supported by domain-specific repositories. For less defined data types, flexible alternatives such as Zenodo and BioStudies allow sharing with fewer requirements (European Organization For Nuclear Research and OpenAIRE 2013; Sarkans et al. 2018). Omics metadata often follows an Investigation-Study-Assay structure (Rocca-Serra et al. 2010), with technology-specific extensions such as metabolite evidence tables (Yurekten et al. 2024) or hybridization probe sequences (Athar et al. 2019). During data upload, repositories may incorporate metadata validation protocols (wwPDB consortium et al. 2019; Yurekten et al. 2024), or require separate formats for metadata (Courtot et al. 2022), often relying on controlled vocabularies and ontologies.
Meeting these requirements requires meticulous data annotation before, during, and after data collection. A major challenge is that data collection often occurs months or even years before publication, risking omission of important details that cannot be recovered later. A significant advance in this area has been the introduction of electronic lab notebooks (ELNs) to replace handwritten notes with digital versions. ELNs range from basic online notebooks that track changes, such as OneNote or Evernote, to advanced platforms with additional functionalities, such as structured folder hierarchies, interlinked assays, templates, controlled vocabularies or integration with a laboratory information management system (LIMS) for sample storage location or compound safety information (Higgins, Nogiwa-Valdez, and Stevens 2022; Kanza et al. 2017; Kwok 2018). Integration of ELNs into data acquisition workflows also facilitate automated collection of essential metadata, such as microscope or sequencer settings (Schmied et al. 2024), data storage location, software versions, and data processing steps. These integrations increase researcher efficiency (Lamprecht et al. 2021; Machina and Wild 2013) and lead to more reproducible and FAIR research (Nijsse, Schaap, and Koehorst 2022).
A particular challenge to ELN adoption is integrating it into the researchers’ daily workflow, as established practices can be slow to change (Foster, Whipple, and Rios 2022). A common workflow used in our institute is computational analysis and modeling in R using R Markdown and its successor Quarto (https://quarto.org/). Using Quarto, one can generate reproducible reports using code (e.g., R and Python) and text side-by-side. However, incorporating these reports into our ELN, RSpace (https://www.researchspace.com/, open-source since 2024) is not straightforward, as they can only be added as attachments. Moreover, reusing (meta)data from RSpace in R is inconvenient as it requires manually downloading files from RSpace.
Here, we present rspacer, a wrapper for the RSpace ELN Application Programming Interface (API). The rspacer package offers a user-friendly set of functions that can automate uploading documents to RSpace, convert Quarto reports to RSpace documents, and facilitate the reuse of metadata from RSpace in R. This integration of the RSpace ELN into the researcher’s workflow streamlines data entry, thereby decreasing the time and energy investment, and at the same time increases (meta)data quality, leading to better reproducibility and ELN adoption.
Implementation
rspacer is an R (R Core Team 2024) package and uses the httr2 package (Wickham 2025a) to wrap a subset of the RSpace API documented at https://community.researchspace.com/public/apiDocs. Its main functionality is divided into three categories, roughly corresponding to different API endpoints: browsing/searching the RSpace file and folder structure, interacting with RSpace documents, and interacting with RSpace Gallery files, used, for example, to add attachments to RSpace documents (Figure 1A).
The R package is available on GitHub (https://github.com/LACDR/rspacer) under an OSI-approved license (MIT), and published to CRAN (G. Burger and Leegwater 2025).
Below, we briefly illustrate how rspacer can streamline common data management and analysis tasks by interacting with the RSpace ELN using easy-to-use functions. A more detailed overview of the package and its functionality can be found on the rspacer website (https://lacdr.github.io/rspacer) and in the package vignettes.
Interact with the API and RSpace folder structure
After installing the rspacer package (see https://lacdr.github.io/rspacer), users must configure API access to their institute’s RSpace instance. This is done by providing the instance API URL, typically the instance URL followed by api/v1 (e.g., https://leiden.researchspace.com/api/v1), and a personal API key, which can be obtained from MyRSpace > My Profile. rspacer provides two ways to configure these variables: the API URL and key can be saved as the environment variables RSPACE_API_KEY and RSPACE_API_URL (recommended, see https://lacdr.github.io/rspacer/articles/rspacer.html#setting-up-rspacer for details). Alternatively, these environment variables can be set for the current session using the set_api_key() and set_api_url() convenience functions. Finally, api_status() checks if a connection to the API can be established using the provided URL and API key. If successful, users can then navigate RSpace’s folder structure using the folder_tree() and document_search() functions (Figure 1B).
Documents & Files
Most rspacer functions interact with documents, as these are the main way to store information in the ELN. An RSpace document can be retrieved by its identifier and is returned as a deeply-nested JSON object converted into an R list object (document_retrieve()). This object includes document metadata, field contents, metadata, and download links for files belonging to this document. However, as field contents are returned as raw HTML, this is not the most user-friendly way to interact with existing documents. Instead, the main added value of rspacer is in creating and updating documents. New documents can be created from HTML files (document_create_from_html()) or tabular file formats such as XLSX, CSV, or TSV (document_create_from_tabfile()); more details are provided in the Applications section below. To create structured documents from HTML, rspacer splits HTML by <h2> headers, placing each section into a field of an RSpace template, which can be specified using a template or form identifier. For tabular file formats, each cell should correspond to the content of a field in an RSpace template, and no further processing is performed. Users can completely revise documents by using the existing_document_id argument to these functions or add additional information to existing fields by using the document_append_from_html() function, resulting in new document versions. Finally, rspacer provides functions to upload and download Gallery files (file_upload() and file_download()), which facilitate working with document attachments (document_list_attachments() and document_add_attachments()). Altogether, this functionality enables a variety of applications, of which we will highlight three examples in the next section.
Applications
Application 1: Reuse of (meta)data uploaded to RSpace
In RSpace, (meta)data, such as a plate layout or a workflow config, can be attached to an RSpace document as files, which are stored in the RSpace Gallery. One can list all attachments linked in a document (document_list_attachments()) and then download these metadata files using their unique identifiers (file_download(), Figure 1C). This allows RSpace to serve as a single source of truth, where multiple users can obtain the same verified (meta)data to perform an analysis. For example, our research group often performs random cell migration assays to study how cancer cells alter their migration in response to drugs or other stimuli (G. A. Burger et al. 2022; Koedoot et al. 2019). Metadata is stored using standardized templates (Hosseini et al. 2023), imaging data is stored internally in OMERO (Allan et al. 2012) and are used to calculate tracks in CellProfiler (Carpenter et al. 2006). The output metrics from CellProfiler, including the mean speed per well, are then processed in R (G. Burger, Heldring, and Wink 2024). rspacer can be integrated into this workflow by downloading the plate layout from RSpace to link the computed migration characteristics to the experimental conditions. After completing the analysis, result files can be uploaded to RSpace (document_add_attachments()), or, even better, the entire analysis workflow can be uploaded to RSpace, as we will discuss in the next application.
Application 2: Uploading LACDR-ISA Quarto reports as lab journal entries
The second application of rspacer is to upload Quarto reports to RSpace. This functionality is especially powerful when a standardized workflow is used for data analysis or for computational modeling. Since in our institute we use an ISA (Investigation-Study-Assay (Rocca-Serra et al. 2010))-inspired ELN organization, we developed Investigation, Study, and Assay Quarto templates (available as a separate R package at https://github.com/LACDR/LACDR.ISA), with matching templates in RSpace (i.e. the headers in the Quarto files correspond to fields in the RSpace templates).
Using these templates, users can follow their usual computational workflow in any language that Quarto supports (most notably R, Python, Julia, and Observable JavaScript) and have the freedom to include any sub-headers, code, or figures within each section (Figure 1D). When rendered, Quarto (via Pandoc, https://pandoc.org/) produces a Quarto report in HMTL (Figure 1D) or any other Pandoc-supported format (e.g., PDF, MS Word, Revealjs, etc.).
Using the rspacer function document_create_from_html(), one converts this HTML report into an RSpace document with the same title and all report sections as separate fields (Figure 1D). The Quarto code (QMD file) and additional metadata files can be added to this document as attachment, a good reproducibility practice. An example Quarto and HTML file are provided within the package, and detailed instructions on how to use these are provided in the package vignettes and website.
Application 3: Uploading tabular files as lab journal entries or as metadata
As described above, tabular files can be uploaded to the Gallery and attached to RSpace documents. However, they can also serve as input for an RSpace document using the document_create_from_tabfile() function. Whereas Application 2 focused on computational outputs, this functionality is more useful in a wet lab context, where experimental conditions are typically reported in tabular files (e.g., Excel). At present, rspacer only supports tabular files with two columns: one for the template field names and one for the field content (Figure 1D). Protected Excel files for Investigations, Studies, and Assays matching our LACDR-ISA standard are included in the supplementary files and online, where only specific cells are editable (Supplementary Files 1, 2 and 3). Instructions on how to use these are provided in the package vignettes and website. This protection in Excel improves template reusability for experimentalists and helps ensure that deviations from the template are minimized.
Potential applications: Automated workflows and uploading experimental metadata
In addition to the applications described above, rspacer allows bioinformatics workflows to integrate more tightly with the RSpace ELN. For instance, rspacer can be used in an R script to upload result files with just a single line of code. Integration into a Shiny app for standardized data analysis could provide a convenient “Upload to RSpace” button, or even uploading all analysis metadata automatically on each run. By storing, for example, file paths, information on the number of files processed, who analyzed the data, the analysis date, and the software versions used, rspacer could facilitate data analysis becoming much more reproducible.
Conclusion
In this article, we introduced a newly developed R package, rspacer, to facilitate interaction with the RSpace lab journal API. This tool enables integrating automated workflows in R with the RSpace ELN. Applications include uploading computational lab journals in HTML format, automating metadata reuse, and uploading data and metadata. These functionalities are particularly beneficial for experiments involving large datasets, complex computational workflows, or combinations thereof. As life sciences datasets grow more intricate, especially in fields using omics technologies, microscopy, and artificial intelligence, data-driven research will keep expanding. This growth will make strong data management strategies even more essential. Implementing an ELN like RSpace is crucial for such strategies, as it ensures data integrity and provenance while serving as a central hub for making data FAIR. This leads to increased reproducibility and reusability of research data. By integrating RSpace into daily workflows, the rspacer package simplifies and streamlines data entry, improving ELN adoption and further reinforcing these benefits.
Acknowledgments
We are grateful for the great R package ecosystem, and in particular for the tremendously helpful “R Packages” book (Wickham and Bryan, n.d.), Quarto (J. J. Allaire et al. 2025), and our package dependencies:
| Package | Version | Citation |
|---|---|---|
| base | 4.5.1 | R Core Team (2025) |
| cli | 3.6.5 | Csárdi (2025) |
| curl | 6.2.2 | Ooms (2025) |
| dplyr | 1.1.4 | Wickham et al. (2023) |
| fs | 1.6.6 | Hester, Wickham, and Csárdi (2025) |
| glue | 1.8.0 | Hester and Bryan (2024) |
| httr2 | 1.1.2 | Wickham (2025b) |
| purrr | 1.0.4 | Wickham and Henry (2025) |
| readr | 2.1.5 | Wickham, Hester, and Bryan (2024) |
| readxl | 1.4.5 | Wickham and Bryan (2025) |
| rlang | 1.1.6 | Henry and Wickham (2025) |
| rvest | 1.0.4 | Wickham (2024) |
| stringr | 1.5.1 | Wickham (2023) |
| tibble | 3.3.0 | Müller and Wickham (2025) |
| tidyr | 1.3.1 | Wickham, Vaughan, and Girlich (2024) |
| xml2 | 1.3.8 | Wickham, Hester, and Ooms (2025) |
| knitr | 1.50 | Xie (2014); Xie (2015); Xie (2025) |
| pkgdown | 2.1.2 | Wickham et al. (2025) |
| rmarkdown | 2.29 | Xie, Allaire, and Grolemund (2018); Xie, Dervieux, and Riederer (2020); J. Allaire et al. (2024) |
| spelling | 2.3.1 | Ooms and Hester (2024) |
| testthat | 3.2.3 | Wickham (2011) |
| usethis | 3.1.0 | Wickham et al. (2024) |
And finally for grateful (Rodriguez-Sanchez and Jackson 2024) for making it easy to be grateful.