domains / families / science / labarchive-integration

labarchive-integration

combined

Electronic lab notebook API integration. Access notebooks, manage entries/attachments, backup notebooks, integrate with Protocols.io/Jupyter/REDCap, for programmatic ELN workflows. Integrates with the official LabArchives ELN REST-like API and Inventory API v1. Supports regional endpoint selection, signed-request construction, user authorization and UID flows, local LA container validation, and verified LabArchives integration workflows.

When to use

• Working with LabArchives REST API for notebook automation
• Backing up notebooks programmatically
• Creating or managing notebook entries and attachments
• Generating site reports and analytics
• Integrating LabArchives with third-party tools (Protocols.io, Jupyter, REDCap)
• Automating data upload to electronic lab notebooks
• Managing user access and permissions programmatically
• The user has LabArchives notebook content and needs a **Methods** draft grounded in recorded procedures.

When not to use

• The user asks for unauthorized access to notebooks or other users' data.
• The user wants clinical recommendations, diagnosis, or treatment language.
• The user asks you to fabricate notebook records, timestamps, protocol details, or compliance statements that are not present in the source.
• The user has no authorized export, no notebook metadata, and no textual record to ground the writing output.

Skill page

Conflict

The three copies describe the same skill name but perform different tasks. The K-Dense copy is a technical API integration guide focused on authentication, regional endpoints, and the distinction between the Legacy ELN API and Inventory API v1. The aipoch copy is an academic writing workflow that uses LabArchives data to generate manuscript sections (Methods, Data Availability, etc.). The FreedomIntelligence copy is a general ELN automation guide focused on notebook operations, backups, and third-party integrations. Because they overlap in the domain of LabArchives but each contains material steps and constraints the others lack (e.g., specific HMAC signing details vs. writing output contracts vs. backup script usage), crowning one would hide the specific use case of the others.