# Overview What is Lab Atlas and who is it for? Lab Atlas is a simple project management platform that helps research teams manage, streamline, and preserve their research assets. Whether you are working in academia or industry, a startup or enterprise, a wet-lab or dry-lab, Lab Atlas can support you and your team. With a single click, Lab Atlas can create a workspace that includes electronic laboratory notebooks (ELN), cloud storage, source code management, and more to ensure your team's work will always be findable and accessible.

Lab Atlas home page

## What can Lab Atlas do? Lab Atlas is first and foremost a project & data management tool. It allows you to register projects, assign teammates, delegate work, and collect results. It also ensures that documents & files related to that work are preserved and easy-to-access for all of your organization's long history. These features include: * A managed project hierarchy with permanent, human-readable IDs. * User roles and access management to manage sensitive data. * Built-in cloud storage and integration with common cloud storage providers (eg. Microsoft SharePoint and Amazon S3), with an integrated file browser. * A rich note editor for drafting detailed documents, as well as integration with ELN providers (eg. Benchling).
## How should I use Lab Atlas? Lab Atlas functions best when you think of it as the hub around which all of your other research record-keeping tasks revolve. It's easy to jump to the conclusion that this tool just generates more busywork for already overworked scientists, but it actually provides a platform to accelerate & simplify the research process by automating-away repetitive tasks and collecting all records into a single place. To get the most benefit, make Lab Atlas the first place you go when preparing to perform a research project. - * Registering projects, studies, and assays will automatically generate storage folders & notebooks you can use to collect results. * If data resides in a system that Lab Atlas does not integrate with, you can create an external link to it to ensure the resource remains findable. * Don't use Lab Atlas as a formal electronic laboratory notebook (ELN) if you already have one, but do use the Notes feature to capture notes that otherwise don't belong anywhere else. * Create shared folders for commonly accessed resources to ensure data is accessible and available.
# Release Notes What's new in Lab Atlas? ## v1.8.0 - August 8, 2026 ### Added * **Personal integrations.** You can now connect services to Lab Atlas under your own account, using OAuth, without an admin configuring them for the whole organization. Your credentials are yours alone and are never shared with other members. * **Egnyte** is now available as a personal integration (beta), for use as project and shared storage. * **A new Integrations page**, visible to every member of your organization. Organization integrations and your own personal connections are managed side by side, with the organization ones still restricted to admins. * **A personal cloud storage folder can now serve as your storage home.** Personal drives are private to their owner and are never shown to other members of the organization. * **A dedicated Tasks page**, plus support for tasks at the project level. Tasks can now be tracked across your whole organization rather than only from within a study or assay. * **An Audit Log**, under Organization Settings. Activity is now classified as research, governance, or administrative. Research activity stays on project, study, and assay timelines; governance activity — membership and visibility changes on a record — appears on both the timeline and the Audit Log; and administrative activity, such as invitations, role changes, and integration connections, is collected in the Audit Log alone. * New activity events for task status changes and assignment, and for integration lifecycle changes. * Organizations on the Enterprise plan can now connect more than one organization integration of the same type. * Public API and MCP additions: project-level task endpoints, a `category` filter on the activity endpoint, endpoints for reading and disconnecting your own personal integrations, and a new `list_project_tasks` MCP tool. ### Changed * Study Tracker imports are now all-or-nothing: an import either lands in full or leaves your organization untouched. A record that cannot be written aborts the run and is named in the reported status. ### Fixed * Organizations in enterprise tenants no longer show the wrong plan when more than one subscription record exists. * New organizations in an enterprise tenant are enrolled in the tenant's configured subscription. * Subscription start, renewal, and trial end dates are no longer displayed as January 1970. * Deleting a Stripe customer in an enterprise tenant no longer fails and retries indefinitely. ## v1.7.5 - August 5, 2026 ### Fixed * Fixed project import, which had degraded since the project creation payload changed earlier in the release cycle. ## v1.7.3 - June 11, 2026 ### Added * User avatars now display when available, instead of initials. ### Fixed * Fixed user lookup that could conflict when a user has multiple email addresses or has changed their email. * Resolved a race condition when users are added to organizations that could result in duplicate user errors. * Fixed a bug that could cause study or assay creation to fail if the parent record had an ELN folder that was not set as the default. ## v1.7.2 - June 9, 2026 ### Fixed * Fixed another bug with enterprise user updates when a user has multiple email addresses or has changed their email since the last sync. ## v1.7.1 - June 9, 2026 ### Fixed * Fixed a bug that would cause user data loading to fail if a single user had changed their email since the last sync. ## v1.7.0 - June 8, 2026 ### Added * **Version 1 of the Lab Atlas public REST API is complete**, including write methods for common resources. * **MCP server tools for reading data from Lab Atlas**, allowing AI assistants to browse your projects, studies, assays, notes, and tasks. This feature is in beta and will expand over time. ### Changed * Integration status now determines whether an integration is usable. Only active integrations can be used; other statuses produce an error with a clearer message about how to resolve it. * Useful error messages are now saved and displayed in the Initialization Failed widget for easier troubleshooting. * Updated how ELN, storage, and Git resources are provisioned when creating projects, studies, and assays. * Updated ELN components for easier folder selection, including Benchling folders below the top level. ### Fixed * Fixed ELN folder unlinking. * Fixed issues with project, study, and assay reinitialization. ## v1.6.1 - May 14, 2026 ### Fixed * Fixed a bug in S3 folder name sanitization that introduced whitespace rather than removing it. * Fixed File Manager folder menu badge styling. * Resolved an organization list fetching issue. ## v1.6.0 - May 4, 2026 ### Added * **A new External User role.** External users have more restricted access than standard users and can only view projects, shared folders, collections, or notes they have been explicitly assigned to. This role is intended for people outside your real-world organization that you would like to collaborate with, without worrying about their access to sensitive data. * **A new ELN tab** on project, study, and assay details pages. As well as creating or linking ELN folders and entries, you can now link a variety of registry entities from external ELN services to records in Lab Atlas, making external data sources easier to track. ### Changed * It is now possible to add ELN associations to existing projects. * Any user can now archive a study or assay they have write permission to. * Integrations that fail five health checks are now disabled automatically. ### Fixed * Added extra validation to authentication tokens. ## v1.5.5 - April 29, 2026 ### Fixed * Security patches. ## v1.5.4 - March 30, 2026 ### Fixed * Security patches. ## v1.5.3 - March 29, 2026 ### Fixed * Fixed a bug that was resulting in incorrect subscription updates. ## v1.5.2 - March 22, 2026 ### Changed * When a user accesses a domain different from their current organization session, they will now be redirected to the Organization List page instead of seeing an error message. * New users invited to existing organizations will no longer automatically get a personal organization created for them if they visit the cloud app instead of the enterprise tenant. ### Fixed * Fixed issues with subscription syncing for enterprise tenants. * Fixed issues with customer portals sessions when no valid customer or subscription record is present. * Fixed an issue with integration services capturing error messages longer than 255 characters. ## v1.5.1 - March 14, 2026 ### Fixed * Fixed an issue that would cause startup of enterprise tenant apps to fail if an organization did not contain the license holder. ## v1.5.0 - March 13, 2026 ### Added * Added new status fields to integration model and more fine-grained recording of the status of integrations. Added periodic health checks of integrations and details logging of integration status change events. * Added automated health check service for integrations, to ensure they are responding and available. * It is now possible to register and use more than one of the same type of integration in a single organization for enterprise domains. * You can now add ELNs to projects, studies, and assays after they have been initialized. It is also possible to add more than one of the same type of ELN or more than one different ELN types to the same record. * Added some new assay, study, and notes summary widgets to details pages. * Added CSV export to some data tables. ### Changed * Benchling notebook templates without fields will not show the field dialog anymore. * Updated integration web components to accommodate the new integration endpoints and data model updates. * Updated the layout and styling of project, study, and assay details pages. ### Fixed * Fixed an issue that could prevent some organization invitations from being accepted. * Fixed an issue that prevented enterprise subscriptions from updating correctly. ## v1.4.1 - January 28, 2026 ### Changed * Organization List page now shows external orgs by default. ### Fixed * Fixed a couple of issues that would cause the client to get hung up if the user was visiting the wrong domain or organization pages. (#LA-329) * Archiving a record will now correctly redirect the user away from the archived record's page. (#LA-331) * Shared folders can now be properly archived and removed from the organization. (#LA-330) * Fixed an issue with revoking invitations and re-inviting deactivated users. ## v1.4.0 - January 6, 2026 ### Changed * Major service updates to all client and web service components. ### Fixed * Fixed note filtering (#LA-319). * Organization list page cards should now show the correct subscription status. Status will also not show unless it is something other than Active (#LA-317). ## v1.3.2 - December 10, 2025 ### Added * You can now add folders from available Shared Folders to projects, studies, or assays directly from the respective details page's Files tab. (#LA-312) ### Changed * You can now archive projects from the organization settings Projects page. * Benchling entry templates with required fields now require you to input those fields before assay or study forms can be submitted. ### Fixed * Fixed an issue that caused by failed notification creation, which would cause record creation to fail. * Fixed an issue preventing SharePoint site drives from being edited. * Added support for Benchling template long\_text fields. (#LA-307) * Fixed a number of broken breadcrumb links. * Imported users can now be correctly invited. ## v1.3.1 - November 19, 2025 ### Changed * Users can no longer change their own role or the role of someone with a higher role. ### Fixed * Fixed a number of issues with the Study Tracker import. * Fixed a bug preventing S3 folders from being added to studies, assays, and projects (#LA-309). * File manager buttons will no longer be hidden when folder is read-only (#LA-300). * Fixed an issue with revoking user invitations (#LA-126). ## v1.3.0 - November 18, 2025 ### Added * Added CDD Vault integration. CDD Vault support electronic lab notebooks for studies and assays. ### Changed * Study Tracker import now allows you to select the programs you want to import, rather than importing everything. ### Fixed * Fixed an issue with Benchling notebook entry creation from templates without schemas. ## v1.2.1 - November 11, 2025 ### Fixed * Fixed an issue with the import wizard that was resulting in duplicate study and assay codes (#CS-23). ## v1.2.0 - November 10, 2025 ### Added * You can now provide required input fields to Benchling notebook entry templates that have entry schemas. A form will display when creating a study or assay and an entry template with fields is selected. * The project import form now allows you to specify a storage location. ### Fixed * Fixed an issue where creating a Benchling notebook entry using a template with required fields would fail, due to none being provided. * Fixed an issue where invalid characters in record names would cause SharePoint folder creation to fail (#CS-21). * Fixed an issue where duplicate slugs could be created where archived records with the same names and codes existed, but slug generation was not catching the duplication. ## v1.1.4 - October 30, 2025 ### Fixed * Fixed an issue where a user's full organization list would not display in the org list page (#CS-17). ## v1.1.3 - October 29, 2025 ### Fixed * Fixed a bad query that would sometimes return archived project, study, or assay records. ## v1.1.2 - October 25, 2025 ### Changed * Updated client URLs to include organization identifiers to allow for easier bookmarking and switching between organizations. ### Fixed * Fixed an issue regarding shared folder access. ## v1.1.1 - October 21, 2025 ### Fixed * Fixed an issue that would prevent temp file storage from taking place in some enterprise tenants. ## v1.1.0 - October 10, 2025 ### Added * Added a public REST API for fetching and writing data to Lab Atlas. Users in enterprise organizations can now access this API to create and manage their own data. Admin users can create API keys that can be used to authenticate requests and allow API calls to act on their behalf. * Added STS:AssumeRole as an option for AWS authentication. ### Fixed * Resolved an issue preventing assays from being created that share the same code with an archived assay (#LA-295, #CS-14). * Fixed an issue that caused files uploaded as assay fields to not correctly transfer and register with the assay (#CS-13, #LA-294). ## v1.0.3 - October 3, 2025 ### Added * Added the ability to view and switch-to external domain organizations from the Organization List page. ### Changed * The 'Unauthorized' page will now direct you to the organization list page. ### Fixed * Non-domain admin users in enterprise tenants can no longer modify subscriptions (#LA-283). * Fixed an issue that locked users out of the organization list page if the current organization subscription state was not active. ## v1.0.2 - September 24, 2025 ### Fixed * Fixed another bug that prevented domain domain switching when the user was already sign into a different domain. ## v1.0.1 - September 23, 2025 ### Fixed * Fixed a bug that prevented domain info from loading when the user was already sign into a different domain. ## v1.0.0 - September 23, 2025 ### Added * Added the new Enterprise tier to the licensing model. This brings support for private domains that are hosted separately from the standard multi-tenant SaaS. Domain admins can manage multiple organizations with separate user pools under a single license. ## v0.9.2 - August 25, 2025 ### Added * Added Study Tracker import to the user interface. Admin users can now import their Study Tracker history through the admin dashboard. ### Fixed * Fixed Benchling template form components not correctly loading entry templates. * A number of fixes for Study Tracker import process. * New assays with linked ELNs should now correctly get links created to the summary notebook entry. ## v0.9.1 - August 12, 2025 ### Fixed * Some improvements to beck-end services. ## v0.9.0 - August 12, 2025 ### Added * Added notifications service to create and display notifications to users in the UI. This includes notifications for user assignments, global announcements, admin alerts, and more. ### Changed * Updated the navbar to move some components out of the user dropdown. ## v0.8.0 - August 8, 2025 #### Added * Added a new Organization list page and streamlined the organization creation process. * Organizations can now be deleted. #### Changed * Updated the licensing plans and their features. Starter plan is now free and allows all integration types, but limits restricted visibility of records and reduces provided cloud storage. * New users will automatically have an organization created for them and be enrolled in the Starter Plan. #### Fixed * Fixed an issue that could prevent organizations with expired subscriptions from resubscribing. ## v0.7.1 - July 16, 2025 #### Fixed * Some improvements to building and deploying the application. ## v0.7.0 - July 14, 2025 #### Added * Added an express import page for quickly importing project, study, and assay records using either and interactive table or an Excel template. (#LA-187) * Implemented Study Tracker import module. #### Changed * Updated the Project details page to add content to the Overview tab. #### Fixed * Fixed assay code generation, which could sometimes result in duplicate codes being generated. * Fixed a bug that prevented shared folder updating (#LA-265). ## v0.6.1 - June 29, 2025 #### Fixed * Fixed an issue that would cause signup process to fail when no subscription was active. ## v0.6.0 - June 8, 2025 #### Added * Added 'sync' method to integration services to allow re-synchronization and test connection between Lab Atlas and external services. * Added support for external links to Project and Assay records. * Added the ability to move studies from one project to another, and assay from one study to another. * Implemented a plugin-based architecture for third-party integrations, making it easier to add new integration types without modifying core code. * Added 'New Assay' button to the Assay list page, allowing users to create new assays directly from the list view. * Updated Assay Type details page and allowed users to create new assays from the Assay Types page. #### Fixed * Data tables will no longer reset pagination when rows are selected (#LA-262). * Fixed sidebar navigation to external sites in compact mode. ## v0.5.7 - May 10, 2025 #### Fixed * Fixed a bug causing the wrong subscription metadata to load in production. ## v0.5.6 - May 9, 2025 #### Fixed * Fixed an issue with the wrong subscription sometimes loading, or the current subscription not loading because the status was not active. * Users should no longer be able to sign up for multiple trials, a new account management page displays when the users has no active subscription but has already consumed their trial. ## v0.5.5 - April 1, 2025 #### Fixed * Fixed an issue that could result in subscriptions not registering quick enough to allow correct organization creation. * Fixed an issue preventing subscription type from updating correctly. ## v0.5.4 - April 1, 2025 #### Fixed * Fixed a bug that was preventing Git repositories from creating correctly. ## v0.5.3 - March 31, 2025 #### Fixed * Invited users now correctly count against license limits (#LA-239). * Page-level errors will now be caught by error boundary (#LA-240). * User initialization failure on secondary organization creation should now be resolved (#LA-241). * Tasks can now only be assigned to users who are members of the project (#LA-169). * Fixed a number of issues with the file manager, including: * Links to external files not opening (#LA-227). * Copying S3 path not working correctly. * File downloads not working correctly for some data sources. * Draggable task cards can now only be gripped from a more visible area. This was also creating problems with the dropdown user select (#LA-225). ## v0.5.2 - March 25, 2025 #### Fixed * Removed jsvectormap dependency and references. This unused library was causing issues in\ production. ## v0.5.1 - March 24, 2025 #### Added * Study and assay notes ill now show up in their parent record's notes tab. #### Changed * Sidebar now defaults to sticky mode for new users. #### Fixed * Fixed some bugs with viewing and updating Team details. * Fixed filtering of notes (#LA-211). * Study tasks should now correctly update what editing studies (#LA-217). * Upgraded TipTap components to address security vulnerability (#LA-192). ## v0.5.0 - March 15, 2025 #### Added * Overhauled the storage data model, adding several new entity types for organization internal\ folders, shared storage folders, and user storage folders. Storage folder access is now\ strictly regulated by the user's project & shared folder permissions. A new file & folder\ picker interface has also been added for easier file & folder selection. * Added tasks feature to studies. Updated task creation, editing, and completion components. * Added optional table view for project list (#LA-125). #### Changed * Updated the Notes model to add explicit classes for Organization, Project, Study, and Assay\ notes. Notes can now be associated with these entities and will be displayed in the\ appropriate context. You can now view all visible notes fom all contexts in the notes list page. * Any admin user can nor modify an organization's subscription plan (#LA-103). #### Fixed * Fixed the display of archived projects admin dashboard. * New Note events will no longer display in timelines. * Fixed an issue preventing project visibility updating. * Fixed a bug preventing project, study, and assay note versions (#LA-168). * Fixed GitLab repository and group naming (#LA-173). * Dismissed 'Getting started' card should now stay hidden (#LA-172). * Fixed a bug that would prevent new users from seeing the organization creation screen. * Fixed a number of bugs with task component display. * Users can no longer assign other privileges higher than their own (#LA-198). * Notes will now render the same in the editor as they do in the viewer. * Fixed account hook lookup and subscription status checks (#LA-201). * Fixed issues with deactivating and re-inviting users (#LA-200). * Clerk should no longer send two confirmation codes on signup (#LA-178). * Study collection description now displays correctly in details page (#LA-208). * You should no longer be able to add users as authors on notes when they don't have access to\ the parent project/study/assay (#LA-202). * Fixed summary timeline card activity display in details pages (#LA-209). * Fixed bugs preventing correct updating of studies, assays, and assay types (#LA-210). * Fixed table filtering (#LA-207). ## v0.4.2 - November 11, 2024 #### Changed * You can now set the status of projects to 'Complete' and 'On Hold'. Only 'Active' projects can be contributed-to by users (#LA-87). * Updated form help popovers to be more visible (#LA-100). #### Fixed * The Example Project now has its status set to 'Complete' by default, to prevent usage by users (#LA-165). * Fixed an issue where archived projects were showing up in the project select input on the new study form. * Fixed 'New Note' button on the home page. * Fixed front page study statistic (#LA-142). ## v0.4.1 - November 7, 2024 #### Added * Completed GitLab integration to allow users to add groups to projects, and create repositories for assays and studies. #### Fixed * Fixed a few minor issues related to feature flags. ## v0.4.0 - October 22, 2024 #### Added * Notes can now be created and associated with projects, studies, and assays. Notes can also be published from the editor now. * New organizations will get demo projects and notes created with example data. * Added GitLab integration. Users can now link their GitLab accounts to their Lab Atlas accounts to create repositories for their studies and assays. #### Changed * Updated to Clerk Core v2 (#LA-133). Also updated some Clerk webhook handlers to properly handle more events. * Updated React Query and Table component libraries. #### Fixed * Updated logging of Stripe service so as not to trigger as many Sentry events. * Removed note content from events to reduce payload size, which was causing some events to fail to be received by EventBridge (#LA-162). * Resolved issue that was causing private user activity to show in the user details page (#LA-161). * Fixed an issue with reading root S3 folders (#LA-156). * Fixed an issue with the File Manager where switching drives/parent folders would not reset path (#LA-163). * Fixed a few issues with Study Collection creation and display pages (#LA-164). ## v0.3.2 - September 15, 2024 #### Fixed * Fixed an issue where the organization selection modal would not close after selecting an organization (#LA-148). * Fixed a bug preventing selected study relationship type from displaying correctly in its form (#LA-149). ## v0.3.1 - September 9, 2024 #### Changed * Removed the head menu from the note editor and replaced it's contents in the text bubble menu. #### Fixed * Fixed incorrect labels showing up in summary timelines (#LA-140). * Fixed error loading My Assays page (#LA-145). * Fixed and issue where old note content would load when trying to create a new note (#LA-141). ## v0.3.0 - September 4, 2024 #### Added * Added a number of plugins to the note editor, including slash-commands, image upload, and more. #### Changed * Updated event type naming to be more flexible and readable. * User preferences are now persisted in the database (#LA-123). * Improved keywords help dialog (#LA-101). #### Fixed * Fixed an issue with Stripe initialization not pulling all records. * Fixed an issue that prevented users from switching organizations when a subscription was not active (#LA-121). ## v0.2.2 - August 18, 2024 #### Changed * Updated the look of the quick action bar for project, study, and assay details pages. #### Fixed * Users can now be removed from organizations, and re-invited (#LA-80). ## v0.2.1 - August 16, 2024 #### Fixed * Fixed Docker build issue. ## v0.2.0 - August 15, 2024 #### Added * Notes feature, which supports creation of rich-text notes with embedded content. * User can create public and private notes, and add authors to help collaborate. * Added some additional brand colors and support for additional CSS theming (eg. buttons). #### Changed * Refactored the web services project and renamed everything to reflect current app name. #### Fixed * Fixed unnecessary errors thrown by account provider and features provider. * Fixed inability to toggle sidebar when in compact mode. * Fixed activity message for study status change (#LA-99). * Fixed an issue that allowed anybody to be assigned to protected or private studies & assays. * Fixed bugs that would cause Benchling form controls to remain hidden when trying to create new studies or assays with parent records that included Benchling folders (#LA-45 and #LA-62). * Fixed 404 error for 'My Assays' page (#LA-115). ## v0.1.0 - July 31, 2024 Initial beta release of the Lab Atlas SaaS application. # Key Concepts Key concepts for getting the most out of Lab Atlas ## Defining your organization Lab Atlas captures and manages your work using a managed hierarchy of several entities: **domains**, **organizations**, **projects**, **studies**, and **assays**. There is enough flexibility in the application to allow you to define & use these entities in almost any way you'd like, but by keeping the following concepts in mind, you will get the most out of Lab Atlas's features.

An example project hierarchy.

### Domains A domain refers to the host of a particular Lab Atlas instance and its URL. Users who sign up at `labatlas.com` and access the application at `app.labatlas.com` are using the primary multi-tenant "cloud" domain. Enterprise tier customers receive a private domain with a custom URL that only their users will be able to access (eg.`dotwisetx.labatlas.com`). Once you are signed-in to any Lab Atlas domain, you can easily hop between the different domains and organizations you are a member of and access all of your workspaces. ### Organizations The organization is the top-level entity in a Lab Atlas domain. Organizations include all of the users you have invited & all of the projects, studies, and assays that they have defined. User roles (such as standard user, power user, and organization admin) are assigned at the organization level. Integrations with external services, such as cloud storage or electronic laboratory notebooks (ELN) are also defined at the organization level. Only users that have been invited into your organization may view its contents. It is possible for a user to be a member of more than one organization, but organization creation may be restricted, depending on the domain context (eg. labatlas.com versus an enterprise domain). Domain Admin users in Enterprise domains will be able to freely create, manage, and access all organizations within their tenant. Standard users in an Enterprise domain will only be able to access the organizations they have been explicitly invited to. ### Projects Projects are loosely defined as long-running efforts by individual users or teams to deliver on organization-level goals. These can be drug discovery projects, broader research efforts (eg. target identification), or house-keeping work (eg. animal facility care or lab maintenance). Projects are top-level entities in Lab Atlas, but have little metadata associated with them, other than a name, description, **code** (used for deriving **study codes**), and visibility setting. This visibility setting defines how non-project-team-members may interact-with the project. Projects primarily serve as buckets for collecting work, which are defined as studies & tasks. They have no defined start or end and are generally assumed to be continuous efforts, until they are marked as complete or inactive. ### Studies Studies are the primary unit of work in Lab Atlas, intended to be finite efforts to complete a specific goal or answer a specific question. Studies can be used to capture long-running experiments (such as animal studies), or short-term activities (such as processing sequencing data). What work a study actually consists of is entirely up to the team performing it. To support this flexibility, only a minimal set of information is required when registering a new study in Lab Atlas: * The parent Project the study is associated with * A name * A description of the study objective * List of study team members * Start date Additional information can be provided, but it is not required. For more granular activity and record tracking, one-or-more assays or tasks can be created within studies. ### Assays & Assay Types Assays represent smaller units of work defined within studies and allow for the capture of more specific experiment metadata, which is enabled through user-defined Assay Types. Assay types are reusable assay templates that allow you to categorize the assay to be performed in flexible ways (eg. histology, sequencing, or plate-based screen), add additional form inputs that users must fill-in when creating the assay, and predefining a list of tasks to be completed during the course of the assay. The use of assay types ensures that commonly-executed assays will have their metadata captured consistently and reliably. ### Study & Assay Codes Study codes are unique identifiers generated every time a new study is registered in Lab Atlas. They are intended both to identify study records within Lab Atlas, as well as outside it, to help tie project information together throughout your information ecosystem. Study codes are generated by combining an alphanumeric prefix, defined by the project, and a numerical suffix, representing the count of studies within the project. Assays are also assigned **assay codes**, which are a concatenation of the parent study code and a numerical counter representing the number of assays within that study. Studies or assays that have added external collaborators are also given a second **external code**, which strips away project-specific identifiers, to allow for sharing outside of your organization. ### File Storage Lab Atlas allows you to share data & documents with your colleagues by bundling cloud storage with each subscription and allowing you to bring your own cloud storage providers with you. Have a SharePoint site or Amazon S3 bucket you want to share with your colleagues? Connect your Microsoft and Amazon Web Services accounts to lab atlas to enable file sharing and storage for your projects. File storage access permissions mirror those of your projects, allowing you to keep your sensitive documents private, while enabling easier sharing with trusted colleagues. ### Tasks Tasks allow you to record additional information about the progress being made in studies and assays. Maybe you want to break them down into simple step-by-step processes, or maybe you just want to be notified when certain tasks have been accomplished. With tasks, you can create simple To-Do lists for your studies & assays, assign them to team members, and capture metadata & files when they are completed. ### Notes Lab Atlas Notes is a simple and powerful way to capture rich-text documents directly in the app and share them with your colleagues. Capture meeting notes, protocols, or observations in an easy-to-use text editor and choose who you share them with. Notes are not intended to replace your existing electronic laboratory notebook (ELN), but rather server as a place to store all of the documents that might otherwise fall through the cracks and be lost on personal devices or in peoples' heads. # Choosing the Right Plan Choosing the right version of Lab Atlas Lab Atlas is available in several different flavors, each of which includes the same core features, but are generally aimed at organizations of different sizes with different business requirements. Most of the available versions are fully-managed, meaning that the application is hosted in the cloud on Dotwise Software's infrastructure, but self-hosted options are also available. A summary of the different versions and their features can be found below. ## Lab Atlas Cloud This is the principal managed version of Lab Atlas, available from [labatlas.com](https://labatlas.com), which anyone can sign-up and start using right away. Lab Atlas Cloud is fully-managed and available globally, allowing teams of all sizes to collaborate and share data, no matter where they are located. Lab Atlas Cloud is available in two different tiers: **Starter** and **Professional**. ### Starter The Starter tier of Lab Atlas provides all of the core features of the application, with a few limitations & restrictions, provided at a discount over the fuller-featured other tiers. Starter is ideal for smaller teams, academic labs, and people who just want to give the application a try before committing to a larger engagement. ### Professional The Professional tier of Lab Atlas Cloud is ideal for larger teams that need the full array of available project management features, but do not require enterprise features, such as single-sign-on. This tier does not have the restrictions of Starter and can support a larger number of users with more complex data needs. ## Lab Atlas Enterprise Lab Atlas Enterprise is a fully-managed application that provides all the features of Lab Atlas Cloud in a private cloud-hosted environment with single-sign-on integration, priority support, and a custom domain. This version allows you to scale your Lab Atlas organization to an unlimited size and provides a number of features required by larger & mature commercial organizations. # Getting Started Signing into Lab Atlas for the first time and preparing your environment for users ## Signing-up and creating your organization If you do not already have a Lab Atlas account, you will first need to signup to create an organization. Go to and complete the signup form.

The signup dialog

{% hint style="info" %} Note: it is possible to use the same email and account for multiple organizations, but a separate subscription is required for each organization in non-enterprise licenses. {% endhint %} After clicking 'Continue', you will be prompted for a verification code. Check your email inbox for a message containing this code, provide it to continue.
Once you have created your account and signed-in successfully, a new organization will be created for you automatically. This organization will be enrolled in the free Starter Plan and have a limited feature set, but you can upgrade to the full-features Professional Plan at any time. Refer to the [Choosing the Right Plan](/introduction/choosing-the-right-plan) section for more information. You can sign-out of the application or view your profile by clicking on your name in the top-right corner of any page and selecting the appropriate item from the dropdown menu.
## Working in your new organization The first time you log into Lab Atlas after signing-up, you will be taken to your organization home page, where you will be presented with a brief introduction to the application and some recommended steps for getting your environment ready for you and your colleagues. Here are the recommended actions you should take before getting to work: * Invite new users & assign them to teams * Connect your electronic laboratory notebook (eg. Benchling) * Connect cloud storage services (eg. Microsoft SharePoint or Amazon S3) * Connect source code management systems (eg. GitLab) * Create Projects and assign users to them
The sidebar is organized into two groups. **Workspace** holds the records you work with every day — Projects, Studies, Assays, Tasks, Collections, Notes and Files. **Organization** holds the shared surfaces: **Users** (the member directory), **Integrations** (connections to Benchling, SharePoint, S3, GitLab and the rest) and **Settings**. Of the tasks above, inviting users is done from **Users**, connecting your notebook, storage and source control from **Integrations**, and creating projects from **Projects**. Teams, assay types, shared folders and your subscription live under **Settings → Organization**.
## Switching between organizations If you are a member of more than one organization, you can switch to a different one by clicking the 'My Organizations' button in the menu bar.
On the new screen, you can select another organization to switch-to or create a brand new organization. If you are a member of organizations in multiple domains (eg. Lab Atlas Enterprise domains), you can click the option 'Show External Organizations' to get a list of member organizations accross all tenants.
# Managing Users & Teams Add and manage users in your organization ## Users Your organization’s members are listed on the **Users** page, reached from the **Organization** section of the sidebar. Every internal member can consult the directory; the controls for inviting, editing and removing users appear for Super Users and above. Before any of your colleagues can start collaborating with you in Lab Atlas, you need to invite them to your organization.
### User Roles A user’s **role** determines what level of privileges they have within the organization and how they can help manage it & access records. By default, the user who creates the organization is assigned the highest-privileged role: **Organization Admin**. When inviting users, you can specify the role you’d like them to assume in the organization. User roles can be changed after they have joined your organization. You cannot assign a user a role higher than yours. Roles are cumulative: each one can do everything the roles below it can, plus more. | **Privilege** | **External User** | **User** | **Super User** | **Organization Admin** | **Account Admin** | | ------------------------------------ | ----------------- | -------- | -------------- | ---------------------- | ----------------- | | Create studies and assays | ✓ \* | ✓ | ✓ | ✓ | ✓ | | Create notes | ✓ \* | ✓ | ✓ | ✓ | ✓ | | File Manager access | ✓ \* | ✓ | ✓ | ✓ | ✓ | | Connect personal integrations | | ✓ | ✓ | ✓ | ✓ | | View the member directory | | ✓ | ✓ | ✓ | ✓ | | Create API keys & use the MCP server | | ✓ † | ✓ † | ✓ † | ✓ † | | Manage users | | | ✓ | ✓ | ✓ | | Create projects | | | ✓ | ✓ | ✓ | | Manage teams & assay types | | | ✓ | ✓ | ✓ | | View the audit log | | | ✓ | ✓ | ✓ | | Manage organization integrations | | | | ✓ | ✓ | | Manage shared folders | | | | ✓ | ✓ | | Manage subscription & billing | | | | ✓ | ✓ | \* Restricted to the projects the external user has been explicitly assigned to — see [External Users](#external-users) below. \† Available on Enterprise plans only. See [Getting Started](/developer-tools/getting-started) under Developer Tools. {% hint style="info" %} **Account Admin** is not assigned when you invite someone — it is held by the person responsible for the organization's subscription. It carries every Organization Admin privilege plus ownership of billing. {% endhint %} #### External Users The 'External User' role is intended for inviting people outside of your real-world organization into your Lab Atlas organization. These might be collaborators, contract research organizations, or contract workers. External users have a more restricted set of permissions than the standard User role: * They can only view projects, collections, shared storage folders, or organization notes that they have been explicitly added to. * They can only create or modify studies & assays in projects they have been assigned to. * They can only view shared folders, organization notes, and collections they have been assigned to. * They cannot view your organization's user list. ### Inviting Users To invite a new user to your organization, click the ‘Invite User’ button in the top-right corner of the Users page. Select the user type (Internal Member or External Collaborator) and provide an email address to send the invitation. For internal users, select the role you wish them to assume.

Internal user invitation dialog

External users do not have roles and will only be able to view & access the projects you assign them to. You can assign internal or external users to existing projects by selecting them from the search input.

External user invitation dialog

User invitations can be managed from the ‘Invitations’ tab. Clicking on the context menu of the invited user will allow you to resend the invitation or cancel it.
### Removing Users Users can be removed from your organization by clicking on a user’s context menu in the Active users table and selecting ‘Remove User’. Once confirming, the user will be deactivated and will no longer be able to log into your organization. Removed users can be viewed in the ‘Inactive’ tab of the Users dashboard, where you have the option to re-invite them.
## Teams Teams are a simple way to group one-or-more users in your organization so that they can be easily assigned to projects, notes, and other resources. When a team is assigned to a resource, all of the users assigned to the team are added. Teams can be created and managed from **Settings → Organization → Teams**.
# File Storage Managing access to cloud storage Lab Atlas provides a limited amount of cloud storage for managing your project documents & files, but also allows you to connect a variety of cloud storage providers (including Microsoft SharePoint & Amazon S3) to allow easier collaboration with your team. Storage providers are connected from the **Integrations** page in the sidebar; shared folders and their access permissions are defined under **Settings → Organization → Shared folders**. ## Storage Concepts Lab Atlas uses a few different concepts to represent file storage systems and make them available to users. Here are a how these are defined and presented to users: * **Storage Drive**: Refers to either Lab Atlas provided cloud storage, or a third-party cloud storage drive object, such as an S3 bucket or SharePoint Site Drive. Drives can be added or removed from the details page of the appropriate integration on the **Integrations** page (eg. AWS for S3, Microsoft 365 for SharePoint). * **Project Folder**: When creating a new project, you are given the opportunity to either create or use an existing storage folder from one of your organization's available Storage Drives. This folder will form the root of your project tree, including all study and assay storage folders created under the project. * **Shared Folder**: Shared folders are a way for you to make storage locations on your connected third-party storage services available to Lab Atlas users within the File Manager interface. You can create a shared folder from locations on any registered drive, define who has access to it, and specify read/write permissions. * **User Folder**: Every Lab Atlas user gets a private user folder that is visible only to them. This folder can be accessed only from the File Manager page. * **Personal Drive**: If you connect a cloud storage service as a [personal integration](/managing-your-organization/third-party-connectors#personal-integrations), a folder on that service can serve as your storage home. A personal drive belongs to you alone — it is never shown to other members of your organization, including admins — and it is reached using your own credentials with the provider rather than the organization's. ## Security & Visibility Keeping your data secure is a principal concern and Lab Atlas provides a number of mechanisms to ensure that files are never accessed by people who shouldn't be able to. Understanding how file storage is implemented and managed is key to keeping your organization secure. Here are some important things to know: * **Project folder permissions are dictated by project visibility.** The [Project documentation page](/managing-your-organization/projects#understanding-project-visibility-and-membership) lays-out a framework for defining who has access to Project records and what they can do with them. Project folders inherit the permissions of the parent project. This means that: * Public project folders are open and write-enabled for everyone in your organization. * Protected project folders can be viewed by non-project members, but not written-to. * Private project folders are not visible to non-members. * External users can only view project folders if they are a member of the project.
* **Organization admins can access any project or shared folder**. This is true even if they are not a member of the project or have had the folder shared with them. * **Only you can access your private user folder.** Not even admins can read or write to this location. * **You cannot navigate above the root folder path.** This is true for all folder types within the File Manager interface. For example, if a shared folder is defined with the path `/data_sets/ds-123`, it is not possible to navigate to the directory `/data_sets` within the File Manager, unless that directory is accessible through another shared folder or project folder. {% hint style="warning" %} Keep in mind when defining project folders and shared folders whether you might be exposing any sensitive subfolders you'd prefer to keep private! {% endhint %} ## Adding Shared Folders Shared folders can be defined from **Settings → Organization → Shared folders**. * Click the 'Add Shared Folder' button. * In the pop-up window, click 'Select a folder'. * In the folder selection dialog, select from the available Storage Drives. * Browse the drive contents to find the folder you would like to share and put a check next to it. If you'd like to use the current folder, check the '\[This folder]' option. Click 'Select'
* Provide a **Display Name** for the shared folder. This will be its label in the File Manager. * Select the appropriate **Visibility** for the folder. * If you select **Public**, everyone in your organization will be able to access the shared folder. * If you select **Private**, only users and teams you add will be able to access the folder. * Check the appropriate boxes to enable write or delete permissions to the folder for users who can access it.

The shared folder creation dialog

* Click 'Save' to complete the shared folder creation. Once saved, the folder will be visible in the Shared Folder settings and can be modified at any time.
# Projects The foundation for your structured research ## Overview Before any studies can be added to your organization, you must first create at least one [Project](/introduction/key-concepts#projects). Projects are the top-level unit of work in your organization, under which you can register as many studies, assays, and notes as you like. You can scope projects any way you like. ## Understanding Project Visibility and Membership A project’s visibility determines who within your organization can view and contribute to it. Regardless of the assigned visibility, everyone who is assigned as a member of the project will have equal permissions to create and modify records associated with it. For organization members not assigned to the project, refer to the table below to understand how a project’s visibility affects people’s ability to interact with it. | **Visibility** | **Permissions** | | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Public | Anyone in your organization can view the project and contribute to it. | | Protected | Anyone in your organization can view the project, but only project team members can contribute to it. Only project team members may be assigned to child records (eg. studies, notes, and tasks). | | Private | Only assigned team members may view or contribute to the project, it will be hidden from all views and selections for non-members. Only project team members may be assigned to child records (eg. studies, notes, and tasks). | {% hint style="info" icon="building" %} ## External Users and Project Visibility The one exception to the above project visibility rules is External Users. An external user can only view projects they are a member of. This means that even if all of the projects in your organization have the 'Public' visibility state, external users invited into your organization will not be able to view them unless they have been made members of the projects. {% endhint %} ## Creating a new Project Projects are created from the **Projects** page in the sidebar. Click the 'New Project' button to enter the project creation form. Most of the fields on this form are important and required, so take a moment to consider them:
* **Name**: Your project must have a unique name. It should not be too long, but should be clear in its definition. * **Code**: This should be a short alphanumeric string, preferably upper-case. It will be used as a prefix for generating study and assay codes. * **Description**: Provide a brief description for your project, explaining its purpose and goal. * **Active**: Unless this is a legacy project no longer in use, this value should be set to 'Active'. ### Adding an Electronic Laboratory Notebook (ELN) If you have configured integration with an ELN (such as Benchling), you can connect your project to an existing project in the application. Choose the project you would like to link your project to from the 'ELN Project' dropdown and all of the required fields will be populated from the ELN platform. It is possible to use the same ELN project for multiple Lab Atlas projects.
{% hint style="info" %} Be sure to create your ELN projects ***before*** adding projects to Lab Atlas. Benchling does not support remote creation of projects through their API. It is also important to make sure that the API account Lab Atlas is using to communicate with the ELN has write access to requested projects. {% endhint %} ### Adding File Storage All projects require a file storage location to create their folder hierarchy for child studies and assays. Select a root folder from the 'Parent Folder' dropdown to use. A new folder named after your project will be created within this root folder and will be used as the default file storage location for all studies and assays created within it. ### Adding Git Repository Group You can optionally also create a group in any integrated Git server (eg. GitLab) to store Git repositories created for studies and assays within your project. Select the root Git Project Group from the dropdown and a subgroup for your project will be created within it. ## Viewing Projects After successful creation of your new project, you will be redirected to the Project Details page. From here, you can modify your project, browse all associated studies, and view all activity in the timeline. Links are also provided to the newly-created folders in your file storage and ELN systems.
# Assay Types Customizing assay workflows with Assay Types ## Overview Assays in Lab Atlas represent the smallest unit of work, typically some repeatable work that might be done in a wet lab or data sciences environment. **Assay Types** are a simple way for differentiating between the types of work being done in different assays and a means of creating templates for work that needs to be documented. They allow you to add additional depth to assays by incorporating some features that enable customizing workflows tailored to your organization: **custom input fields** and **tasks**. Input fields allow capturing additional information in a variety of inputs when creating new assays. Tasks allow you to create 'To Do' lists for your assays and assign work to colleagues. ## Adding new Assay Types Every new assay in Lab Atlas requires the user to select an assay type. By default, each instance comes with a built-in 'Generic' assay type, which serves as a default when no others are available. Admins can add additional assay types from **Settings → Organization → Assay types**. From here, click the 'Add Assay Type' button. On the new page, provide some basic descriptive information about your new assay type. {% hint style="info" %} Every member can browse the assay types defined in your organization from the **Assays → Assay types** entry in the sidebar. Creating and editing them happens in Settings. {% endhint %}

Assay type summary

If custom fields are needed for the assay type, click 'Add Field' under the 'Input Fields' heading to create a new field card. For each input field, provide the following information: * Select the field **type** you would like to define. This type will determine what type of input controls will be presented to the user when they create a new study with this assay type. * Provide a field **name** and optional **description**. The description can be used to describe to users how the field is intended to be used. * Use the checkbox to mark the field as **required**. Required fields must be filled out when creating a new assay. * If the selected field type supports it, you can optionally provide a **default value** or **selectable options**. * The order of each field card specifies the order the input controls will be presented to users when creating a new assay. You can change the order by dragging-and-dropping the cards.

Example assay type fields

Assay tasks can be defined for your assay type in the 'Tasks' section. Click 'Add Task' to generate a new task card. Provide the following information for each task: * Give the task a **label** that describes the work to be done. * You can optionally add one or more input fields to the task, which users will be prompted to fill-in when completing the task. These can be defined in the same way as described above. * The order of each task card specifies the order the task controls will be presented to users when creating a new assay. You can change the order by dragging-and-dropping the cards.
# Third-Party Connectors Connect the tools you use with Lab Atlas Lab Atlas allows you to connect a variety of third-party tools, such as cloud storage providers, electronic laboratory notebooks, and source code management systems. These integrations allow you and your team to pull files & data in from these systems, as well as propagating records & automating actions in the external services. Everything below is managed from the **Integrations** page in the sidebar, which every member of your organization can open.

The integrations page

## Organization and personal integrations Integrations come in two kinds, and the difference matters for who can set them up and who can use them. An **organization integration** is connected once by an admin and shared by everyone in the organization. It uses a single set of credentials belonging to the organization, and the resources it exposes — an S3 bucket, a SharePoint site, a Benchling tenant — are available to members according to the normal project and folder permissions. Only Organization Admins can connect or modify one. A **personal integration** is connected by you, for you, using OAuth. You sign in to the provider yourself, Lab Atlas never sees your password, and the connection acts strictly as you. Nobody else in your organization can see or use it, and a storage folder reached through a personal integration is never shown to other members. Any member can connect one, with no admin involvement. ## Organization integrations * [Benchling](/integrations/benchling) * Automate creation of notebook folders & entries * [Microsoft 365](/integrations/microsoft-azure) * Read and write files from SharePoint * Automate creation of storage folders for projects, studies, and assays * [Amazon Web Services](/integrations/amazon-web-services) * Read and write files from S3 * Automate creation of storage folders for projects, studies, and assays * [GitLab](/integrations/gitlab) * Automate the creation of source code groups and projects * [CDD Vault](/integrations/cdd-vault) * Automate creation of notebook entries ## Personal integrations * [Egnyte](/integrations/egnyte) * Connect your own Egnyte account for project and shared storage To connect one, open the **Integrations** page and choose the provider from the personal section. You will be sent to the provider to sign in and approve access, then returned to Lab Atlas. You can disconnect it again at any time from the same page, which revokes Lab Atlas's access immediately. {% hint style="info" %} Because a personal integration acts as you, the folders it exposes follow your own permissions in the connected service — not your Lab Atlas organization's. Storage reached this way stays private to you. {% endhint %} # Audit Log Reviewing governance and administrative activity across your organization The Audit Log is a single, org-wide trail of the changes that affect who can see and do what in Lab Atlas. Where a project, study, or assay timeline answers "what work happened on this record?", the Audit Log answers "who was given access to what, and when?". You will find it under **Settings → Organization → Audit log**. It is available to Super Users and above. ## How activity is classified Every event Lab Atlas records falls into one of three categories, and the category determines where you see it. | Category | What it covers | Where it appears | | ------------------ | ---------------------------------------------------------------------------------------------------------------------------- | -------------------------------------- | | **Research** | The day-to-day work on a record — creating and updating studies and assays, adding notes, completing tasks. | Record timelines only | | **Governance** | Access and visibility changes scoped to a single record — adding someone to a project team, changing a project's visibility. | Record timelines **and** the Audit Log | | **Administrative** | Organization-level changes — inviting or removing users, changing roles, connecting or disconnecting integrations. | The Audit Log only | The effect is that a record's timeline stays readable as a history of the science, while everything with a governance or compliance dimension is also collected in one place an admin can review. ## Reading the log Entries are listed newest first and paged twenty at a time. Each one records what happened, which record or user it affected, who performed it, and when. Some of the things you will find here: * Users invited, joining, being removed, or having their role changed * Members and teams added to or removed from a project * A project's visibility changing between Public, Protected, and Private * Integrations being connected, disconnected, disabled by a failed health check, or re-enabled * Tasks being assigned, or moving between statuses {% hint style="info" %} API and MCP traffic is recorded the same way as work done in the web interface. A key acts as the person who created it, so activity performed by a script or an AI assistant is attributed to that user and shows up here alongside everything else. {% endhint %} # Importing Data From Study Tracker How to migrate your Study Tracker data to Lab Atlas Have a [Study Tracker](https://studytracker.io/) instance you would like to migrate your data from? Moving your data and resuming work in Lab Atlas is easy. {% hint style="success" %} For best results, try importing your Study Tracker data into a fresh Lab Atlas organization. This will reduce the likelihood of duplications or naming conflicts between existing records. {% endhint %} ### Exporting your data from Study Tracker {% hint style="info" %} Data export is only supported in Study Tracker version 1.0 or later. {% endhint %} Exporting data from Study Tracker requires a user with admin privileges. Log in to your instance, go to the admin dashboard, and select 'Data Export' from the menu. Click the 'Start Export' button to begin the process. It shouldn't take longer than a minute or two, after which a ZIP file will be downloaded in your browser containing the full export.
### Importing your Study Tracker Data into Lab Atlas Once you have your Study Tracker export in ZIP file format, log in to your Lab Atlas organization and go to the Organization Setting dashboard. Open up the Utilities menu and select 'Study Tracker Import'. Click 'New Import', select the ZIP file you exported from Study Tracker, then click submit. Depending on the size of your Study Tracker history, the import process can take upwards of an hour to complete. The import takes place asynchronously in the background, but it is recommended to wait for the import to complete before performing any additional actions in Lab Atlas. If you naviaget away from the import page, the process will continue, but you will no longer see the progress or be notified when it completes.
Once the import completes, proceed to the next section of this document to take the required steps before resuming your work in Lab Atlas. If the import results in an error, click the link in the error notification to send an email to our support teams so that we can help troubleshoot the issue. ### After the import After the import completes, there are a few things you will need to do before you can resume working in Lab Atlas: #### Re-invite Users The Study Tracker import process will add all of the users from your old instance to Lab Atlas, including all of their project associations & history, but they will not be able to log until they have a Lab Atlas account created for them. This can be accomplished through the [Users page](/managing-your-organization/managing-users#users), reached from the **Organization** section of the sidebar. Click on the context menu next to each user you would like to invite to Lab Atlas and click 'Re-Invite User'. They should receive an email shortly inviting them to create an account, if they do not have one, or join your organization if they already have an account.
#### Update Integration Credentials All of your third-party integrations from Study Tracker will be transferred into Lab Atlas and configured, but their credentials will need to be provided again in order to validate & encrypt them. For each integration, do the following: * Go to the [Integrations page](/managing-your-organization/third-party-connectors) in the sidebar * Select the integration to update * Click the 'Actions' button and select 'Edit Registration' * Enter the required credentials in the pop-up form and then submit.
# Studies & Assays Creating and working with studies ## Overview [Studies](/introduction/key-concepts#studies) and [Assays](/introduction/key-concepts#assays-and-assay-types) are the primary units of work in Lab Atlas and make up the bulk of record keeping, but how you choose to define and utilize them is entirely up to you ([we do provide some guidance](/using-lab-atlas/frequently-asked-questions#how-should-i-define-studies-and-when-should-i-add-new-ones)). You generally want to think of assays as well-defined activities that have a standard protocol, which are expected to be completed within a short amount of time be only one or two people. Studies are a bit more open-ended and may cover a longer period of time & include more people, but should still have a clearly-defined goal. When you are ready to perform some wet- or dry-lab work on a new study or assay, Lab Atlas should be the first place you go before getting started. The reason for this is that Lab Atlas will take care of some of the repetitive first steps in preparing the systems you are required to work within by creating a few things for you: * A unique [Code](/introduction/key-concepts#study-codes) that can be used to identify your study in the lab or in other systems. * A folder and summary notebook entry in your linked electronic laboratory notebook system (eg. Benchling). * A folder in your linked cloud storage service (eg. SharePoint or Amazon S3) for capturing documents & results. * An optional source code repository in a connected Git server (eg. GitLab) for managing data science notebooks. You can reference the below diagram for an example workflow for when and how to use Lab Atlas:

Example study workflow

# Creating & Updating Studies ## Creating Studies Studies can be created from a number of different pages, including the home page. On the 'New Study' page, you will be presented with a number of different inputs for describing and adding features to your study. Most of these inputs are not required, but can add a lot of value to your study when used properly.
### Study Overview This section defines the required inputs that provide context for your study. These include: * **Name**: A brief but descriptive name for the study. This name and the generated **study code** will be used to label notebook, storage folders, and other records created by Lab Atlas. * **Project**: Select the [Project](/managing-your-organization/projects) you wish to associate the study with. This will also determine where storage and ELN folders will be created. * **Description**: Describe your study's purpose and goal in a few sentences. * **Start Date**: Select the date the study is expected to begin. * **End Date**: Optional. If the study has already completed, you can set the end date. * **Aliases**: Optional. If the study has any other identifiers you would like to associate, you may add them here. That's it. If no other information is required and you would like to get on with your work, you can click 'Submit' at the bottom of the page and the study will be created. If you'd like to provide more information or enable additional features, you can use some of the other inputs below. ### Study Members If more than one person will be working on this study, you can search-for and add them to the study using the Study Members inputs. These people will also be added as authors on any ELN notebook entry that Lab Atlas will create for you. By default, you will automatically be added. You can remove yourself from the study by adding another user and then clicking the 'x' button next to your name.
{% hint style="info" %} **Note:** the parent Project you have selected affects which users you can add to the Study. If a Project is Protected or Private, only users that are a member of the Project Team will be able to be added to the Study. {% endhint %} ### External Collaborators If your study is being performed externally or in collaboration with an external party, you can add an association with that party in the 'CRO/External Collaborator' section. Lab Atlas can also generate **External Study Codes**, which can be provided to collaborators in place of the internal study code, so as not to expose any sensitive information that might be embedded in it.
* From the dropdown list, select the collaborator you would like to associate with the study. * If an External Study Code has already been provided by the collaborator or CRO, you can enter it in the External Code field. If not, a code will be generated for you and added to the study **Aliases** list. * Select the collaborator from the list of registered organizations. If the collaborator you are looking for in not in the list, click the 'Add New Organization' button to register a new one. The Organization Code field will be used as a prefix for generating external study codes.
### Tasks Tasks are a simple method of creating TO-DO style worklists and assigning them to team members for completion. If you'd like to create one or more tasks for the study, you can do so here. More information about creating and using Tasks can be [found here](/using-lab-atlas/tasks).

Adding a task to a study

### ELN Folders & Notebook Entries If the project you selected to associate your study with has a linked ELN project, your study will automatically receive a new ELN folder and summary notebook entry from a blank template. You can also choose to create this summary notebook entry from a registered template in your ELN system. Search-for and select the template you'd like to use from the 'Notebook Entry Template' dropdown. If you do not want an ELN folder & notebook entry created for your study, you can uncheck this option before submitting the 'New Study' form.

The ELN folder and notebook dialog

### Keywords Keywords tag your study so it is easier to find and filter later. You can add as many as you like, choosing from the keywords already used in your organization or creating new ones as you type. Because keywords are shared across the organization, reusing an existing one is usually better than coining a near-duplicate — it is what makes a keyword useful for grouping related studies that live in different projects. Keywords can be added or removed at any time by editing the study. ### Adding a Git Repository If you would like to create a source code repository for your study in a linked Git server, you can click the switch in the 'Git Repository' section to add one. This will create a repository within the Git group that was assigned to your selected project when it was initialized. If no Git group exists for the selected project, a new one will be created for it.

The Git repository dialog

# Working with Studies So you've created a study...now what? Once a study has been registered in Lab Atlas, there are a number of things you can do to capture important data, collaborate with colleagues, and move the project forward. The Study Details page collects a summary of your study & associated records, and provides some tools for continuing your work. This is presented in a tabbed view that breaks up the components by category. ## The Study Details Page The Study Details Page can be reached by either clicking a study link on the Study List page or from a Project's study list. From here, you can view and manage all of the details of a study and its lifecycle. The details page is split up into a number of sections (eg. Files, Tasks, Timeline, etc)., which can be accessed by clicking on the tabs at the top of the page. There are also two useful controls that can be found in the top-right corner: the Status Button and Actions Button. ### Changing Study Status Newly created studies are assigned a status of 'Active', which is displayed in the Status Button in the 'Summary' card of the details page. You can quickly and easily change the status of your study by clicking the Status Button and selecting a new status.
{% hint style="info" %} Changing the status of a study will not prevent you from performing additional actions. You can still operate within a study as normal if it has been marked as Complete, Cancelled, or Cancelled. {% endhint %} ### Study Options Menu The Options button in the top-right of the details page is a dropdown that includes a number of useful functions. Some of these are recommended next steps (eg. mark as complete), some are shortcuts (eg. create assay), and others are maintenance functions (eg. archiving & editing).
{% hint style="info" %} Certain actions require either study membership or elevated privileges. If you do not see a particular action, you probably do not have permission to perform it. {% endhint %} ### Study Overview The Overview tab displays a high-level view of all of the key study metadata, activity, and resources. From here you can quickly gauge the status of the study, jump to key resources, and take any required next steps. The Summary card displays the study's description, code, keywords (if any were given), team members, and relevant timestamps (creation date, last updated, start date, etc).
### External Links If you are working in a web-based tool that Lab Atlas cannot integrate with or just want to link another web page to your study, you can use External Links. Clicking on an existing link will open a new browser window and take you to the linked resource. To add a new external link, simply click the 'Add' button, provide the URL of the resource and a descriptive label, and then click 'Save'. Links can be removed by clicking the red 'x' next to the link.

Several study external links

### Study Relationships Sometimes there is a direct relationship between studies that is important, but not immediately clear. You can highlight these relationships by creating links to other studies in the 'Study Relationships' section.
Click the 'Add' button, the select the study you wish to link and the relationship that best fits. After clicking 'Save', a bidirectional link will be created between the current study and the study you selected. The relationship type that is associated with the other study will be the inverse of the initial relationship. For example, a user creates a new relationship for Study `ABC-123` that declares that study `XYZ-456` is its parent. On the details page of study `XYZ-456`, a record will display stating that study `ABC-123` is its child.

Creating a new study relationship

### Study Collaborators You can view the existing associated study collaborators on this page, as well as add additional ones. If you associated a collaborator with your study when creating it, but did not enter an External Code, the generated codes can be found here.
# Creating & Updating Assays ## Overview Assays are created from the Study Details page, either going to the 'Assays' tab and clicking 'Add Assay' or by clicking the Actions button on the page and selecting 'New Assay'. Much like with [creating studies](/using-lab-atlas/studies/creating-studies#creating-studies), most of the input controls are optional, allowing you to get to work quickly on your assay, but utilizing all of the available tools can add a lot of value to your workflow. The assay form also includes a number of additional features not found in studies.

The assay form overview section

### Assay Overview This section defines the required inputs that provide context for your assay. These include: * **Name**: A brief but descriptive name for the assay. This name and the generated **assay code** will be used to label notebook, storage folders, and other records created by Lab Atlas. * **Assay Type**: Select the [assay type](/managing-your-organization/assay-types) you wish to use for your assay. If the assay type includes any additional inputs or predefined tasks, they will populate further down the page. * **Description**: Describe your assay's purpose and goal in a few sentences. * **Start Date**: Select the date the assay is expected to begin. * **End Date**: Optional. If the assay has already completed, you can set the end date. * **Aliases**: Optional. If the assay has any other identifiers you would like to associate, you may add them here. That's it. If no other information is required and you would like to get on with your work, you can click 'Submit' at the bottom of the page and the assay will be created. If you selected an assay type with required inputs, you will need to provide them before continuing. If you'd like to provide more information or enable additional features, you can use some of the other inputs below. ### Assay Members If more than one person will be working on this assay, you can search-for and add them using the Assay Members inputs. These people will also be added as authors on any ELN notebook entry that Lab Atlas will create for you. By default, you will automatically be added. You can remove yourself from the assay by adding another user and then clicking the 'x' button next to your name.
### Assay Type Inputs Assay Types can be defined with a list of custom inputs users must provide when creating a new assay. If your selected assay type contains any of these inputs, they will be populated in the form and you will be prompted to provide input. Required fields will be marked with asterisks (\*).
### External Collaborators If your assay is being performed externally or in collaboration with an external party, you can add an association with that party in the 'CRO/External Collaborator' section. Lab Atlas can also generate **External Codes**, which can be provided to collaborators in place of the internal assay code, so as not to expose any sensitive information that might be embedded in it.
* From the dropdown list, select the collaborator you would like to associate with the assay. * If an External Code has already been provided by the collaborator or CRO, you can enter it in the External Code field. If not, a code will be generated for you and added to the assay **Aliases** list. * Select the collaborator from the list of registered organizations. If the collaborator you are looking for in not in the list, click the 'Add New Organization' button to register a new one. The Organization Code field will be used as a prefix for generating external codes.
### Tasks Tasks are a simple method of creating TO-DO style work lists and assigning them to team members for completion. If you'd like to create one or more tasks for the assay, you can do so here. More information about creating and using Tasks can be [found here](/using-lab-atlas/tasks).

Adding a task to a study

{% hint style="info" %} Assay Types can be predefined with a list of default tasks. When you select an Assay Type at the top of the assay form, if the selected assay type has predefined tasks, they may overwrite any tasks you have already defined below. {% endhint %} ### Keywords Keywords tag your assay so it is easier to find and filter later. You can add as many as you like, choosing from the keywords already used in your organization or creating new ones as you type. An assay's keywords are its own — they are not inherited from the parent study, and adding one here does not change the study. Keywords are shared across the organization, so reusing an existing keyword rather than coining a near-duplicate is what makes them useful for grouping related work. Keywords can be added or removed at any time by editing the assay. # Study Collections Grouping studies that span projects Study Collections are a simple way to organize studies that span multiple projects or contexts. A collection can represent a meta-study, group the studies backing a regulatory filing, or just gather work you want to keep an eye on in a single place. A study lives in exactly one project. That is the right model for ownership, but it is a poor fit for the many reasons you might want to look at a set of studies together. Collections solve that: a study can belong to any number of collections, and adding it to one changes nothing about the study itself. ## Collections versus projects Reach for a **project** when you are deciding where new work belongs. A project owns its studies, supplies the code prefix, and determines where storage and notebook folders are created. Reach for a **collection** when you want to view existing work through a different lens. Collections own nothing, create nothing, and can be made and discarded freely. The same study can sit in a discovery project, a regulatory-submission collection, and a personal reading list at the same time. ## Creating a collection Click **Collections** in the sidebar, then **New Collection**. * **Name** — what the collection is for. * **Description** — optional, but worth writing. Collections are often assembled for a reason that will not be obvious to a colleague six months later. * **Visibility** — see below. * **Members** — the users who can contribute, for Protected and Private collections. ## Visibility Visibility controls both who can see a collection and who can change what is in it. | Visibility | Who can see it | Who can add or remove studies | | ------------- | -------------------------------- | -------------------------------------------- | | **Public** | Everyone in your organization | Anyone in your organization | | **Protected** | Everyone in your organization | You and the users assigned to the collection | | **Private** | You and the users assigned to it | You and the users assigned to the collection | Use **Protected** for a curated set that others should be able to read but not reshape — a regulatory bundle, for instance. Use **Private** for work in progress or anything sensitive. {% hint style="info" %} A collection never widens access to a study. Someone who cannot see a study in the first place will not see it through a collection, no matter how the collection's visibility is set. {% endhint %} ## Adding and removing studies Open the collection, click the **Actions** menu, and choose **Manage Studies**. The dialog lets you search for studies across every project you have access to, and add or remove them in one pass. Removing a study takes it out of the collection only — the study, its assays, notes, files, and notebook entries are untouched. Because a study can be in as many collections as you like, there is no cost to adding it to a second one. # File Management ## The File Manager The File Manager page allows you to browse and interact with the various storage locations associated with your account in a unified environment. At the top, a dropdown provides a list of all of the folders you can browse. These include your private user folder, project folders, and any shared folders you have access to. More about these folder types can be [found here](/managing-your-organization/storage-folders#storage-concepts). Select one of the available folders to browse its contents.
## Project, Study, and Assay Files The details page of projects, studies, and assays has a Files tab that allows you to browse and interact with the files & folders associated with the record. The interface is mostly the same as the File Manager, but the folder menu options also include a context menu that provide some additional options.
## Browsing Storage Folders After selecting one of the available storage folders to browse from the menu, the contents of that folder will be loaded and displayed in the interface. There are a number of ways to interact with the interface to explore the folder contents. * Clicking on a folder name will move you into that folder and load its contents. * Clicking on a file link will open that link in a new window (if a public URL is available for the cloud storage system). * You can navigate backwards or upwards in the directory path using the controls at the top of the interface or by clicking on any of the folder names in the breadcrumbs. * You can search the current folder for items by name by using the Search bar. This will only match against file and folder names, not their contents. * You can use the pagination controls at the bottom of the interface to page through folders with a large amount of contents. * You can sort the table by name, size, or modification date. ## File Management Actions A number of actions are available from the 'Actions' button in the File Manager interface or from the various context menus in the files table or folder menu. ### Creating folders Click the 'Actions' menu and select 'Create folder'. In the pop-up window, enter the name of the folder you wish to create and then click 'Create'. The interface will refresh to show the newly created folder.

The folder creation dialog

{% hint style="info" %} The created folder might be named slightly different than your input if you used unsupported characters. Some file systems do not allow white space or special characters in folder names. {% endhint %} ### Uploading files Click the 'Actions' menu in the interface and select 'Upload...'. In the pop-up window, you can either drag-and-drop the files you wish to upload or click the 'Select files' button and choose them manually. Once selected, click 'Upload all' to send them to the target folder. The interface will refresh once complete to show the newly uploaded files.
### Downloading Files Files can be downloaded directly from the file manager interface by clicking on the context menu of the file you wish to download and clicking 'Download'.
### Adding folders to projects, studies, and assays It is possible to link a folder so that it will show up in the Files tab of project, study, or assay details pages. Click on either the context menu for the folder you would like to link, or the Actions button in the File Manager (for linking the current folder), and select 'Add to...'. In the pop-up window, select the record type you would like to link the folder to, then search for the record.
{% hint style="warning" %} It is important to note that linked folders will inherit the visibility of the linked record. If you link a private shared folder to a public project, everybody in the organization will be able to view the folder contents in the project details Files tab. {% endhint %} ### Removing folders from projects, studies, and assays If you would like to remove a folder that has been attached to a project, study, or assay, navigate to the details page Files tab. Select the folder from the dropdown. In the folder context menu on the right, select 'Remove' and then click 'Submit'.
{% hint style="info" %} You cannot remove a folder if it is the primary folder or if it is the only available storage folder. {% endhint %} ### Changing the default storage folder The default storage folder for a project, study, or assay is the folder in which all new uploads & child folders will be created by default. You can change the default folder from the Files tab in the details page. Select the folder you'd like to make default from the menu on the lft and click the '...' to open the context menu. Click 'Set as default'. # Tasks Tracking and delegating work across projects, studies, and assays Tasks are Lab Atlas's to-do list. They let you break work into steps, hand a step to a colleague, set a deadline, and — where it matters — capture data at the moment the work is signed off. A task always belongs to a **project**, a **study**, or an **assay**. That parent decides who can see the task, since a task inherits the visibility of the record it hangs from.

The tasks page

## The Tasks page Click **Tasks** in the sidebar to see every task you have access to in one place, rather than hunting through records one at a time. Three tabs narrow the list: * **All tasks** — everything you can see. * **My tasks** — tasks assigned to you. * **Created by me** — tasks you raised, whoever is doing them. Two filters narrow it further: by **status**, and by **source** (project, study, or assay). Tasks are grouped by deadline rather than by parent record, so the list reads as a schedule: **Overdue** first, then **Due today**, **Tomorrow**, **This week**, **Later**, and **No due date**. Closed tasks collapse into a **Closed** group at the bottom, out of the way but still there when you need them. ## Statuses A task moves through four statuses. | Status | Meaning | | --------------- | ------------------------------------------------------------------------------------------------- | | **Open** | Raised, not started. | | **In progress** | Someone has picked it up. Useful on long-running work so the rest of the team can see it moved. | | **Done** | Finished. | | **Incomplete** | Closed without being finished — the work was abandoned, superseded, or turned out to be unneeded. | **Incomplete** matters more than it looks. Deleting a task that was never done erases the fact that it was ever planned; marking it incomplete keeps the record honest, which is the point of an audit trail. Open and In progress are *active* and appear in the due-date groups. Done and Incomplete are *closed* and collapse into the Closed group. {% hint style="info" %} The REST API and MCP server use the underlying values `TODO`, `IN_PROGRESS`, `COMPLETE`, and `INCOMPLETE`. The web interface shows `TODO` as "Open" and `COMPLETE` as "Done". {% endhint %} ## Creating a task Click **New task** on the Tasks page, or add one from the Tasks tab of any project, study, or assay. Tasks can also be created inline while filling in the New Study or New Assay form. You will be asked for: * **Title** — what needs doing. * **Description** — optional detail, protocol steps, or links. * **Attach to** — the project, study, or assay the task belongs to. Prefilled when you create the task from a record. * **Assignee** — optional. Leave it unassigned if anyone can pick it up. * **Due date** — optional. Tasks with a due date are flagged as overdue once it passes. Assigning a task notifies that person and puts it in their **My tasks** list. It does not lock the task: anyone with access to the parent record can still complete it.

Creating a new task

## Tasks that capture data A task can be defined with **fields** that must be filled in before it can be closed. This turns a checklist item into a small record-keeping step — a reading to note, a batch number, a confirmation that a control passed. When a task has required fields, the detail panel shows how many are still outstanding, and the completion button reads **Record & complete** rather than **Mark complete**. You cannot mark it done until every required field has a value. This is how you make sure the information gets captured at the point the work actually happened, rather than reconstructed later.

A task that requires user information before completion

## Tasks from assay types An [assay type](/managing-your-organization/assay-types) can define a list of default tasks. Every assay created from that type starts with those tasks already in place, so a standard protocol arrives as a ready-made checklist and gets recorded the same way every time. {% hint style="warning" %} If you change the assay type part-way through filling in the New Assay form, the newly selected type's default tasks may replace any tasks you have already added. {% endhint %} # Customizing Your Experience ## Display Preferences You can modify the look and feel of Lab Atlas from the User Preferences menu. Click on the 'Preferences' icon in the menu bar to open the Preferences screen.
### Sidebar Mode By default, the sidebar is set to **Sticky** mode, where it will always be fully visible and within the view frame, even if you scroll down the page. In **Fixed** mode, the sidebar will still be full-size, but will scroll away as you move down the page. In **Compact** mode, the sidebar takes up much less space and only the icons for each menu items is displayed by default (hovering over the menu will show options).

Compact versus stick sidebar comparison

### Theme A number of colorful themes are also available for customizing the look of Lab Atlas. The **Default** theme provides some contrast between light and dark elements. If you prefer a different experience, try out the **Light** and **Dark** themes.

Dark theme

# Frequently Asked Questions (FAQ) Quick answers and guidance for common questions ## How should I define projects and when should I add new ones? Projects represent the highest-level unit of work in Lab Atlas and are used for grouping child studies and assays. How you choose to define them is really up to your organization and its needs — think of a project as a long-running effort that may or may not have an expected end date. A few examples we have seen: * Target Identification * Disease areas (eg. cancer or liver disease) * General platform or functional groups (eg. lab operations or platform development) * Drug discovery, preclinical, and clinical programs There is no need to plan or expect all related studies over the lifetime of an organization to fall under a single project. In the above example, it is likely that what eventually becomes a clinical-stage effort might start in Platform Development or Target ID before graduating to a preclinical project of its own. Study relationships and collections can be used to maintain links between studies grouped into different projects. With this in mind, you should think about adding new projects whenever you feel like an effort has outgrown the existing ones, or whenever it feels like you are bundling too many unrelated studies into the same project. ## How should I define studies and when should I add new ones? Study records in Lab Atlas are vaguely defined on purpose, allowing you to define a study in a number of different ways. A study can be a short-term sequencing experiment completed in a day-or-two, or it can be a long-running animal study that has many steps and may take multiple months. The one guiding principal for defining studies should be that they have a defined plan and definite end date. The study proposal, protocol, and results should be captured in your organization's electronic laboratory notebook, but a summary should be provided in the study description in Lab Atlas. If additional work needs to be done for a study that has already been completed, it is probably better to create a new study and link it to the existing one, rather than add additional assays to a study that has already been marked complete (though Lab Atlas will not prevent you from doing this). # Microsoft 365 Enabling file management in SharePoint Lab Atlas can be connected to your organization's Microsoft 365 account to enable project file management in Sharepoint. Connecting your SharePoint workspace to Lab Atlas is a two-step process: 1. Create an Entra ID App. 2. Register the app with Lab Atlas. {% hint style="info" %} **Note**: Configuring Lab Atlas access to SharePoint requires access to the Microsoft Azure portal. If you do not have access, contact your local IT help desk for help with this process. {% endhint %} ## Creating an Entra ID App Access to SharePoint is accomplished with an Entra ID (formerly Active Directory) application, which grants Lab Atlas the ability to access your environment through Microsoft's Graph API. * Log into the [Azure portal](https://portal.azure.com/). From the services menu, select Microsoft Entra ID. * On the Entra ID page, make a note of the **Primary Domain** value.
* Click the 'App Registrations' tab in the 'Manage' menu, and then click the 'New Registration' button. * Give your application a distinct name (eg. Lab Atlas). Under 'Supported Account Types', make sure the default value is selected ("Accounts in this organizational directory only"). Do not add a Redirect URI. Click 'submit'.
* When you are redirected to the details page for your new application, make a note of the **Client ID** and **Tenant ID** values.
* We also need to generate a Client Secret ID for authentication. Click 'Add a certificate or secret'. * On the next page, click 'New client secret'. In the window that opens, provide a name for your secret key and set the expiration date. Click 'Add'.
{% hint style="warning" %} **Important:** If you set an expiration date for your key, be sure to refresh your secret and update Lab Atlas before the expiration date! {% endhint %} * When your secret key is created, make a note of the **Value** and **Secret ID** values. * Next, we need to grant your application permission to access resources in your Microsoft account. Click on the 'API Permissions' tab of the application details page. * Click 'Add a permission'. When asked to choose an API, select 'Microsoft Graph'. When asked to choose permission type, select 'Application Permissions'. * Search-for and add the following permissions: * `Files.ReadWrite.All` * `Sites.Read.All` * `User.Read.All`

The required API permissions

{% hint style="info" %} If you'd prefer not to grant Lab Atlas access to all of your organization's SharePoint sites, you can use the `Sites.Selected` permission in place of `Sites.Read.All`. You can refer to this article for instructions on granting your Entra ID app access to sites: {% endhint %} * You will notice that some of the selected permissions require consent to be granted on behalf of the organization. Unless you are logged-in as an admin user, you will have to to get an admin to sign in and perform this task for you. ## Registering your Entra ID App in Lab Atlas * Log into Lab Atlas, click **Integrations** in the sidebar, and select 'Microsoft 365'. Click the button to add a new registration. * In the popup window, provide the following information: * **Name**: a display name for your Azure integration or account. * **Domain**: the primary domain of your Microsoft account, as found in your Azure AD dashboard. This typically takes the format of `myorganization.onmicrosoft.com`. * **Tenant ID:** the tenant/directory ID of your Azure AD app. * **Client ID**: the client/application ID of your Azure AD app. * **Client Secret**: the secret value generated for your Azure AD app (not the Secret ID).
* Click 'Submit'. If the information you have provided is correct, the integration will complete successfully and the Azure Integration page will reload.
## Adding SharePoint Document Drives Once you have successfully integrated your Microsoft environment, you can connect SharePoint site document drives to Lab Atlas. Currently, this serves only to allow Lab Atlas to browse and write project files & folders to the Drives that support SharePoint sites. Lab Atlas does not have the ability to read or publish any other SharePoint data, and does not have the ability to connect to private OneDrive Drives. * Click the 'Add SharePoint Site' button. * On the popup window, search-for and select the SharePoint Site you want to connect to. * Select from the available site drives you would like to connect. * Provide a **Display Name** for the Drive. This is the label that will be used in Lab Atlas. * Provide the directory you would like to be the **Root Path** of the drive. {% hint style="info" %} Any directory above the Root Path will *not* be accessible or visible to users in Lab Atlas. {% endhint %}
* Click 'Submit' to complete the registration. Once complete, the selected SharePoint Site and attached Drive will be displayed on the page.
{% hint style="info" %} Before you can browse or write project files to connected drives, you have to [add a Root Storage Folder](/managing-your-organization/storage-folders#adding-root-folders). {% endhint %} # Amazon Web Services Connecting your Lab Atlas instance with S3 The Amazon Web Services (AWS) Simple Storage Service (S3) is a powerful cloud storage system that is great for collecting & processing data, but not great for sharing with colleagues in a user-friendly way. Lab Atlas helps bring this service to a wider audience within your organization by allowing you to attach S3 buckets as storage drives and use them for project storage & shared storage folders. ## Configuring Lab Atlas Access in AWS Lab Atlas accesses AWS through the official Java SDK libraries and can authenticate & authorize access to your environment using one of two options: IAM role assumption or user access keys. The most secure way to grant access to Lab Atlas is to create a role that Lab Atlas can assume in your account and attaching the minimum-required permissions to allow the application to read & write from your target buckets. This method allows for simple access management and is easy to turn-off, if desired. {% hint style="info" %} **Note**: Configuring Lab Atlas access to AWS requires access to the AWS Console with a user with admin privileges. If you do not have access, contact your local IT help desk for help with this process. {% endhint %} #### Before you get started Regardless of which authentication option you provide to Lab Atlas, you will first need to create an IAM policy that grants access to the required resources. * Log into the AWS console and navigate to the IAM dashboard. * Select 'Policies' from the Access Management menu and then click 'Create policy'. * A new window will open for creating a new IAM policy. Select the JSON format option and then past the content of the code block below into the policy editor. Change the bucket names to match the buckets you'd like to access in Lab Atlas. * Create a name for the policy, provide a description, and save the policy. ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "ListAllBuckets", "Effect": "Allow", "Action": "s3:ListAllMyBuckets", "Resource": "arn:aws:s3:::*" }, { "Sid": "AccessSpecificBuckets", "Effect": "Allow", "Action": [ "s3:ListBucketVersions", "s3:ListBucket", "s3:GetBucketLocation" ], "Resource": [ "arn:aws:s3:::bucket1", "arn:aws:s3:::bucket2" ] }, { "Sid": "ReadWriteObjectsInSpecificBuckets", "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:ListBucketMultipartUploads", "s3:PutBucketPublicAccessBlock", "s3:AbortMultipartUpload", "s3:DeleteObject", "s3:PutObjectAcl", "s3:GetObjectVersion", "s3:ListMultipartUploadParts" ], "Resource": [ "arn:aws:s3:::bucket1/*", "arn:aws:s3:::bucket2/*" ] } ] } ``` If you are going to use role assumption to allow Lab Atlas to authenticate with AWS, you also need to get the unique 'AWS External ID' from the application in order to securely configure the role to be used. #### Option 1: Creating an IAM role Lab Atlas can assume * Log into the AWS console and navigate to the IAM dashboard. * Select 'Roles' from the Access Management menu and then click 'Create role'. * On the next screen, select the 'AWS account' trusted entity type (to allow connections from other accounts). * Under the AWS account options, select 'Another AWS account' and provide the account number: `886436948912` * Under 'Options', check 'Require external ID' and provide the ID you acquired from Lab Atlas. * Click 'Next' when ready.
* On the next screen, select the Policy that you created earlier that will grant access to your buckets and other resources to Lab Atlas. Click 'Next' when ready.
* Provide a descriptive name and description for the role. Add a tag with the name `LabAtlas` and a value of `enabled`. You can also add tags to the role to allow better tracking of Lab Atlas activity within your account. Complete the creation of the role.
Once complete, the trust policy on the role should look something like this: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::886436948912:root" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "la-xxxxxxxxxxxxx" } } } ] } ``` The tags on the role should look like this:
#### Option 2: Creating a user access key * Log into the AWS console and navigate to the IAM dashboard. * Select 'Users' from the Access Management menu and then click 'Create user'. * On the next screen, provide a descriptive name for the user. Do *not* check the box to grant AWS console access. Click 'Next'.
* On the next screen, select 'Attach policies directly'.
* Search for the policy you created by name and select it. Click 'Next'. On the next screen, add any tags appropriate for your organization, then click 'Create user'.
* Back on the IAM user list page, search for and select your new user. In the user summary view at the top of the next page, click 'Create access key'.
* On the next screen, you will be presented with a list of use-cases for your key (and recommendations for alternatives). Select 'Third party', then click 'I understand...' at the bottom of the page. Click 'Next'. Optionally provide a key description and then click 'Create access key'.
* On the next screen, copy and save the **Access Key** and **Secret Access Key** values in a safe place. ## Connecting your AWS Account in Lab Atlas Once you have an access key created that is associated with an IAM user with appropriate privileges, you can register the integration in Lab Atlas. * Open Lab Atlas, click **Integrations** in the sidebar, and select 'Amazon Web Services'. * Click the 'Register Integration' button.
* In the pop-up window, provide the required information: * A display name for the integration. * Your AWS account number (optional). * The AWS region for the account. * The access key ID and secret access key you created for the integration.

The AWS integration registration form.

* After clicking 'Submit', Lab Atlas will test the credentials you provided. If access is granted, the window will close and the integration registration details will be displayed.

A successfully created registration

## Adding S3 Buckets Once you have connected Lab Atlas to your AWS account, you can add S3 Buckets from the same integration details page. * Click the 'Add S3 Bucket' button and a popup will appear:
* Select a bucket from the list of available buckets. Keep in mind: the IAM policy that grants access to AWS might not allow read/write access to all of the buckets in this list. Provide a display name and the root path you want like to grant access to, and then click 'Submit'. * The new bucket should now appear in the list of connected buckets in the AWS integration settings screen. You can now use this bucket for project storage or creating shared folders.
# Benchling Configuring Lab Atlas to use the Benchling ELN. Lab Atlas can connect with Benchling to help you streamline your lab notebook workflows. By connecting your tenant and associating Benchling projects with Lab Atlas projects, you can automatically generate notebook folders and entries every time you create a Study or Assay in Lab Atlas. ## Preparing Benchling Lab Atlas integrates with Benchling using the ‘Apps’ feature, which allows access to the REST API without the need for providing user credentials. Instead, an App is registered within Benchling and assigned to each project Lab Atlas needs access to, with the appropriate permissions. If you have already added the Lab Atlas app to your tenant, skip to the [next section](#adding-the-lab-atlas-app-to-projects). ### Registering a Lab Atlas App in your Benchling tenant Sign into your Benchling tenant with a user that has admin privileges and access to the Developer Console. The Developer Console can be accessed by clicking your user icon n the bottom-left of the screen, selecting Feature Settings, and then clicking 'Developer Console'.

The feature settings menu in Benchling

Select the 'Apps' option from the Developer Console menu and then click 'Create App'. On the new screen that pops-up, select to create a new app 'From scratch'. Provide a name and brief description. Select 'Private' as the audience.
Once created, you will be redirected tothe app's details page. On the overview tab, click the + button to create a new **Client Secret**. Save that and the **Client ID** value in a safe place. These values will be entered into Lab Atlas when connecting your tenant.
Click on the 'Version History' tab. You should only see a single version of the app that you just created. Click the 'Install' button and then confirm the installation in the pop-up to install the app in your tenant.
### Adding the Lab Atlas App to projects Once your Lab Atlas App is installed in your Benchling tenant, you can begin associating it with organizations and projects you'd like it to have access to. Go the the Tenant Admin console in Benchling. If you click on the 'Apps' tab here, you should see the Lab Atlas app, along with any other apps you have installed in your tenant. Click 'Organizations' and then click the name of the first organization you'd like to add Lab Atlas to. In the new organization window, click the 'Apps' tab. You'll notice that the Lab Atlas app does not yet show up here. Click the 'Search for an app' bar and search for the app you created. Once you select the app, it will be added to your organization. Make sure the Role value is set to 'Member'.

Lab Atlas app successfully added to an organization

Next, you need to add the app to each project you would like to connect. In the Organization window, click the 'Projects' tab. Click the :gear: icon next to a project to open the Project Settings window. Click 'Manage Access'. In the new window, click the search bar and search for your app. Select it, set the permissions to 'Write', then click 'Add'. Click the 'Save' button on the window to close it and save you changes. Repeat this step for each additional project you'd like to allow Lab Atlas access to.
## Connecting Lab Atlas to your Benchling Tenant Once you have created your App in Benchling and assigned it to all of the relevant projects, you need to link it with your Lab Atlas organization. In Lab Atlas, click **Integrations** in the sidebar and select 'Benchling'.

The Benchling settings page, before connecting your tenant

Click the 'Add Registration' button to open up the 'New Benchling Registration' dialog. Fill in the following information: * A display name for the connection (eg. your Benchling organization name). * The Benchling tenant name. This matches the subdomain of your Benchling tenant URL. So for example, if your organization's Benchling URL is `https://company-x.benchling.com`, then the tenant name is `company-x`. * The Client ID of the app you created in Benchling. * The Client Secret of the app you created in Benchling.

The registration creation screen

After you click 'Submit', Lab Atlas will test that it is able to connect to your Benchling tenant and read from it. If successful, you will be taken back to the Benchling integration overview page and your new connection will be visible.

A successfully connected Benchling tenant

## Adding Benchling Projects to Lab Atlas You can associate Benchling projects with Lab Atlas projects when creating them. Fill in the New Project form information as normal, then at the bottom of the page, under the 'Electronic Laboratory Notebook Folder' section, select your Benchling project from the 'ELN Projects' dropdown. This will fill in the appropriate information to allow Lab Atlas to connect to your Benchling project when creating studies.
# GitLab Using GitLab to create study groups and projects. Lab Atlas supports integration with GitLab cloud or Community Edition (aka. Omnibus) via its REST API. Once configured, users can choose to create Git repositories to be linked to their studies & assays, so that computational workflows and source code can be captured. {% hint style="info" %} If you are using a privately-hosted GitLab instance, it must have a public IP or domain, otherwise Lab Atlas will be unable to reach it. {% endhint %} ## Preparing GitLab for Lab Atlas Integration Lab Atlas will use a single GitLab group for creating study repositories. A sub-group will be created for each Lab Atlas project, under which GitLab projects (aka. Git repositories) will be created for both studies and assays. It is best that you start fresh with an empty group and use it exclusively for Lab Atlas-created repositories. ### Create a new Group in GitLab. This needs to be done by an administrator. Give your project a clear name. Be thoughtful about how you set the Visibility Level of the group. For private GitLab instances, to ensure that projects are accessible to colleagues who do not have GitLab licenses, you should set the Visibility Level of the group 'Public'. For hosting on GitLab cloud, it is probably not wise to make your study projects available to the public internet.
Once the group has been created, make a note of the 'Group ID' that is displayed on the summary page. ### Access Tokens Once the group has been created, you need to allow Lab Atlas to access it using the GitLab API. Access can be granted securely through the use of Access Tokens, which can be defined either at the group or user level. #### Creating a Group Access Token The simplest and most secure way to grant access is with a [Group Access Token](https://gitlab.internal.vesaliustx.com/help/user/group/settings/group_access_tokens), which can be created in the group settings menu by someone with the appropriate privileges. The access token should be granted the 'Maintainer' role and 'api' scope, allowing it to create and access subgroups and projects.
The created access token can be used to authorize API requests, without the need to authenticate a user. This is done by passing it in the `Authorization` header with the `Bearer` prefix (eg. `Authorization: Bearer abcd-122324i534i`). Be sure to save this token in a safe place. #### Creating a User Access Token If you would prefer that Lab Atlas has access to all of the groups in your GitLab instance that your personal user does, you can create a User Access Token instead. Click on your user icon (usually top-left) and select 'Preferences'. Select the 'Access tokens' menu item, then click 'Add new token'.
On the next screen, give your token a name and set an expiration date some time in the future (be sure to create a reminder for yourself to refresh the token). From the list of scopes, check 'API'. Click 'Create token'. On the next screen, copy and save the secret token.
## Registering your GitLab instance in Lab Atlas GitLab integrations are registered from the **Integrations** page in the sidebar. Select 'GitLab', then click 'Add Integration' to open up the configuration dialog.
In the pop-up window, provide the required info for your integration: * A display name for the integration. * The root domain for the server (eg. ). * The access token created in the previous steps. Click submit to create the registration. If the registration fails, check that you provided the correct information and that there is at least one visible group associated with the token. # CDD Vault Connecting Lab Atlas to your CDD Vault Lab Atlas can connect to [CDD Vault](https://www.collaborativedrug.com/) and use it as your electronic laboratory notebook. Once connected, Lab Atlas creates a notebook entry each time you register a study or an assay, so the record in Lab Atlas and the write-up in CDD Vault stay tied together without anyone copying identifiers between the two. CDD Vault is an **organization integration**: an admin connects it once, using a single API key, and everyone in the organization uses that connection. See [Third-Party Connectors](/managing-your-organization/third-party-connectors) for how organization and personal integrations differ. ## What Lab Atlas does with it * Creates a notebook entry for each new study, in the CDD Vault project linked to the study's parent Lab Atlas project. * Creates a notebook entry for each new assay. * Links existing CDD Vault projects to Lab Atlas projects, from the project form or a project's ELN tab. * Reads back entry content so it can be viewed from within Lab Atlas. {% hint style="info" %} CDD Vault does not have nested folders the way Benchling does. Where Benchling gives a study its own folder, CDD Vault entries are created directly in the linked project. {% endhint %} ## Preparing CDD Vault You need an **API key** from a CDD Vault account with access to the vault and projects you want Lab Atlas to write to. {% hint style="warning" %} Every action Lab Atlas performs is carried out as the user that owns the API key, and entries it creates are attributed to that user. Use a dedicated service account rather than a person's own login where you can — a key tied to an individual stops working the day they leave. {% endhint %} To generate one, sign in to CDD Vault, open your account settings, and create an API key. Make a note of the value; you will paste it into Lab Atlas in the next step. Confirm that the account holding the key has write access to each project you intend to link. Lab Atlas cannot create a project in CDD Vault — the project must already exist. ## Connecting in Lab Atlas Click **Integrations** in the sidebar and select **CDD Vault**, then click the button to add a registration. Fill in: * **URL** — optional. The root URL of your CDD Vault tenant, only if it differs from the default. * **API Key** — the key you created above. It is stored encrypted and never displayed again. * **Vault** — once the API key is entered, Lab Atlas queries CDD Vault for the vaults the key can reach and offers them in a dropdown. Choose the one you want to use. Submit the form. Lab Atlas tests the credentials before saving, so a failure here means the key is wrong or lacks access, rather than something being wrong later. {% hint style="info" %} If you edit an existing registration you will be asked to re-enter the API key. Lab Atlas cannot show you the stored value, so it needs the whole key again to re-validate and re-encrypt it. {% endhint %} ## Linking projects With the integration connected, you can associate a CDD Vault project with a Lab Atlas project — either when creating the project, in the 'Electronic Laboratory Notebook Folder' section of the New Project form, or afterwards from the project's **ELN** tab. Once a Lab Atlas project is linked, studies and assays created within it will offer to create a CDD Vault notebook entry. A project can be linked to more than one ELN, and the same CDD Vault project can back several Lab Atlas projects. If a study form reports that the selected project has no usable CDD Vault folders, the parent project has not been linked yet — add the link from its ELN tab and try again. # Egnyte Using Egnyte for project and shared storage

The Egnyte integration management page

# Getting Started Lab Atlas gives you two ways to work with your data programmatically: * **REST API** — a versioned HTTP API (`/api/v1/`) for scripts, integrations, and automation. * **MCP server** — a Model Context Protocol endpoint (`/mcp`) that lets AI agents (Claude Code, claude.ai, the Anthropic API) read your Lab Atlas data with natural-language prompts. Both surfaces authenticate with the **same API key**, scoped to your user and organization. Whatever you can see in the web app, your key can see — no more. {% hint style="info" %} API and MCP tools are currently limited to Enterprise customers only. {% endhint %} ### Create an API key Every member of your organization can create their own API keys — no admin role is required. Each key belongs to the person who created it and carries that person's permissions. {% stepper %} {% step %} #### Open the API keys page Click **Settings** in the sidebar, then go to **API access → API keys**. {% endstep %} {% step %} #### Create a new key Click **New API Key**. In the **Create API Key** dialog, fill in: * **Name** — a label to recognize the key later (max 64 characters). * **Duration** — how long the key stays valid: **7**, **30**, **90**, or **365** days.
Then click **Submit**. {% endstep %} {% step %} #### Copy and store the key Your key is shown once, in the form `lak_.`. Use the **reveal** and **copy** buttons to grab it, then store it somewhere safe (e.g. a secrets manager or environment variable). {% hint style="warning" %} This is the **only** time the full key is displayed. If you lose it, revoke it and create a new one. {% endhint %} {% endstep %} {% endstepper %} You can revoke or delete keys at any time from the same page.
### Use the REST API Pass your key in the `X-API-KEY` header. The base URL is `https://.labatlas.com/api/v1/`. ```bash curl https://.labatlas.com/api/v1/projects \ -H "X-API-KEY: lak_xxxxxxxx.xxxxxxxxxxxxxxxxxxxx" ``` {% hint style="warning" %} Use `X-API-KEY` (or `Authorization: ApiKey `). Do **not** use `Authorization: Bearer …` — that scheme is reserved for the internal web client and will be rejected on `/api/v1/`. {% endhint %} For the full endpoint list, pagination, permissions model, and error formats, see the [Public API Reference](/developer-tools/rest-api-reference). ### Connect via MCP Point your MCP client at `https://.labatlas.com/mcp` over **Streamable HTTP**, sending your API key in the `X-API-KEY` header. {% tabs %} {% tab title="Claude Code" %} ```bash export LABATLAS_API_KEY=lak_xxxxxxxx.xxxxxxxxxxxxxxxxxxxx claude mcp add --transport http labatlas \ https://.labatlas.com/mcp \ --header "X-API-KEY: $LABATLAS_API_KEY" claude mcp list # expect: labatlas ✓ connected ``` {% endtab %} {% tab title="claude.ai" %} In **Settings → Connectors**, add a custom connector: * **URL** — `https://.labatlas.com/mcp` * **Transport** — HTTP / Streamable HTTP * **Header name** — `X-API-KEY` * **Header value** — your Lab Atlas API key {% endtab %} {% tab title="Anthropic API" %} ```json { "mcp_servers": [ { "type": "url", "url": "https://.labatlas.com/mcp", "name": "labatlas", "headers": { "X-API-KEY": "lak_xxxxxxxx.xxxxxxxxxxxxxxxxxxxx" } } ] } ``` {% endtab %} {% endtabs %} For the full tool list, example prompts, and troubleshooting, see the [MCP User Guide](/developer-tools/mcp-server). # REST API Reference How to use the Lab Atlas public API The Lab Atlas public REST API lets external clients — scripts, integrations, internal tooling, and partner systems — interact with the same projects, studies, assays, and supporting resources that the Lab Atlas web client uses. This guide explains how to obtain credentials, authenticate requests, and call each endpoint. {% hint style="info" %} The Lab Atlas public API is currently available only to Enterprise customers. {% endhint %} {% hint style="warning" %} The public API is currently in beta, some endpoints and their conetns may change over time. {% endhint %} ### Quick start ```bash # Set your tenant base URL and API key export LA_BASE=https://your-tenant.labatlas.com export LA_KEY=lak_xxxxxxxx.xxxxxxxxxxxxxxxxxxxx # List the projects visible to your account curl -s "$LA_BASE/api/v1/projects" \ -H "Authorization: ApiKey $LA_KEY" | jq . # Create a new project curl -s -X POST "$LA_BASE/api/v1/projects" \ -H "Authorization: ApiKey $LA_KEY" \ -H "Content-Type: application/json" \ -d '{ "code": "MYPROJ", "name": "My Project", "description": "Created via the public API.", "visibility": "PRIVATE" }' ``` *** ### Getting an API key API keys are issued from inside the Lab Atlas web application. Each key is owned by a specific **organization user**, and every request made with that key executes under that user's permissions — there is no separate service account. To create a key: 1. Sign in to your Lab Atlas tenant. 2. Open the user menu in the top-right corner and choose **Account settings**. 3. Select the **API keys** tab. 4. Click **Create new key**. 5. Give the key a memorable display name (for example, `lims-importer`, `nightly-backup`) and choose how long it should remain valid. 6. Copy the key value from the modal that appears. **This is the only time the full key value is shown.** Store it somewhere safe — a secret manager, your CI's environment variables, or an encrypted note. You can also list, rotate, or revoke your existing keys from the same screen. Revoking a key takes effect immediately; any request presenting the revoked key will fail with `401 Unauthorized`. > **Heads up:** the API-key UI is only available when your Lab Atlas tenant has the Enterprise feature flag enabled. If you do not see the **API keys** tab, contact your administrator. A key value looks like `lak_.`. The `lak_` prefix and `keyId` segment are stable identifiers; the segment after the dot is the secret material. #### Per-user, per-organization Each key is bound to exactly one `(user, organization)` pairing. If you belong to two organizations, you need a separate key for each. Switching your active organization in the web UI does not change the org a previously-issued key is scoped to. #### Key lifecycle | Action | Result | | --------- | ------------------------------------------------------------------------------------------------------------- | | Create | Key is active and usable immediately | | View list | Shows key metadata only (display name, creation date, last-used time). Secret material is never re-displayed. | | Rotate | Revoke the old key and create a new one. There is no atomic rotation primitive. | | Revoke | Future requests with this key return `401 Unauthorized`. The key remains in the audit log. | | Expire | Keys expire automatically after their configured duration. Expired requests return `401`. | *** ### Authentication Every request to `/api/v1/**` must present a valid API key. Two header formats are accepted; pick whichever fits your client best: ```http Authorization: ApiKey lak_xxxxxxxx.xxxxxxxxxxxxxxxxxxxx ``` ```http X-API-KEY: lak_xxxxxxxx.xxxxxxxxxxxxxxxxxxxx ``` > **Do not use `Authorization: Bearer …`.** Bearer tokens are reserved for the internal `/api/i/**` API and will be rejected on the public endpoints. Missing, expired, malformed, or revoked keys return `401 Unauthorized` with no response body. Keys that are valid but lack the permission required for the action return `403 Forbidden`. #### Required transport All requests must be made over HTTPS. The API enforces HSTS and will reject plain-HTTP traffic at the load balancer. #### CORS The public API is intended for server-to-server use. Cross-origin browser requests are not enabled by default. If you need to call the API from a browser-based application, deploy a thin server-side proxy in front of it. *** ### Permissions model Because every key is bound to an organization user, authorization decisions follow the same rules used by the web UI: * **Visibility** — `findAll` and `findById` endpoints only return resources the key's owning user can view. For projects this is determined by the project's visibility setting (`PUBLIC`, `PROTECTED`, `PRIVATE`) plus the user's role and team memberships. * **Contribute** — `create`, `update`, `delete`, `status`, and `archive` endpoints require the user to be a project member (or higher). Calls that fail this check return `403 Forbidden`. Looking up a record the user cannot view returns `404 Not Found` instead — this is intentional and avoids leaking the existence of records the user has no business knowing about. * **Admin-only operations** — Team writes and Assay-Type writes additionally require the `ORGANIZATION_ADMIN` role on the owning user. A non-admin key on these endpoints returns `403`. If you revoke a user's admin role, every key they own immediately loses access to admin-only endpoints. *** ### Conventions #### Base URL & versioning | Mount | Status | | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `/api/v1/...` | Current. Use this. | | `/api/beta/...` | Deprecated. Still resolves to the same handlers, but every response carries a `Deprecation: true` header and a `Link` header naming the `/api/v1` successor. | | `/api/i/...` | Internal API used by the Lab Atlas web client. **Not for external use.** API keys are rejected on this mount. | {% hint style="warning" %} The public API was originally published under `/api/beta`. If you built against that mount, swap the prefix for `/api/v1` — the paths, payloads, and behavior are otherwise identical. {% endhint %} #### Content types All requests and responses use `application/json` with UTF-8 encoding. #### Resource identifiers Identifiers are UUIDs (version 4), serialised as canonical lowercase strings with hyphens — e.g. `b1d1b15a-19e0-4d6f-8d33-7a3d3aef6cba`. #### Dates Dates are ISO 8601 strings in UTC. Both date-only (`2026-05-06`) and date-time (`2026-05-06T14:32:11.000+00:00`) formats are accepted on input. #### Pagination List endpoints return a page object compatible with Spring Data's `Page` envelope: ```json { "content": [ { /* DTO */ }, { /* DTO */ } ], "totalElements": 142, "totalPages": 8, "size": 20, "number": 0, "first": true, "last": false, "empty": false, "pageable": { "pageNumber": 0, "pageSize": 20, "sort": { /* ... */ }, "offset": 0, "paged": true, "unpaged": false } } ``` You can request a specific page and size using query parameters: ``` GET /api/v1/projects?page=2&size=50&sort=name,asc ``` | Param | Default | Notes | | ------ | ----------------- | --------------------------------------------------------------------------------- | | `page` | `0` | Zero-indexed. | | `size` | `20` | Maximum permitted size depends on the resource; large pages may be capped at 200. | | `sort` | resource-specific | `field,direction` pairs. Repeat the parameter to sort by multiple fields. | #### Status codes | Code | Meaning | | ------------------ | ------------------------------------------------------------------------------------------------ | | `200 OK` | Successful read or update. Response body present. | | `201 Created` | New resource created. Body contains the created representation. | | `204 No Content` | Successful delete. No body. | | `400 Bad Request` | Malformed payload or invalid query parameter. | | `401 Unauthorized` | Missing, expired, malformed, or revoked API key. | | `403 Forbidden` | Authenticated but lacking the required permission (e.g. not a contributor, or not an org admin). | | `404 Not Found` | Resource does not exist, or does exist but the key's owner cannot view it. | | `409 Conflict` | Concurrent update conflict or duplicate identifier. | | `5xx` | Server-side error. Try again or contact support if it persists. | *** ### Endpoint reference The tables below list every public endpoint. Path-prefix is `https:///api/v1`. Where an endpoint requires `ORGANIZATION_ADMIN`, this is noted in the right-most column. #### Projects Projects are the top-level container for studies and assays. | Method | Path | Description | Auth | | ------ | --------------------------------------------- | ---------------------------------------------------- | ----------- | | GET | `/projects` | Paginated list of projects visible to the caller. | Member | | GET | `/projects/{id}` | Fetch a single project. | Member | | POST | `/projects` | Create a new project. | Member | | PUT | `/projects/{id}` | Update name, description, visibility, etc. | Contributor | | POST | `/projects/{id}/status` | Change project status. Body: `{"status": "ACTIVE"}`. | Contributor | | POST | `/projects/{id}/archive?archived=true\|false` | Archive or restore. | Contributor | | DELETE | `/projects/{id}` | Delete the project (and its studies, assays). | Contributor | **Create example** ```bash curl -X POST "$LA_BASE/api/v1/projects" \ -H "Authorization: ApiKey $LA_KEY" \ -H "Content-Type: application/json" \ -d '{ "code": "OPLAB", "name": "Operations Lab", "description": "Ops experiments for FY26.", "visibility": "PROTECTED", "status": "ACTIVE" }' ``` **Project status values**: `CREATED`, `INITIALIZING`, `INITIALIZATION_FAILED`, `ACTIVE`, `COMPLETE`, `ON_HOLD`, `DEACTIVATED`. **Visibility values**: `PUBLIC`, `PROTECTED`, `PRIVATE`. **Choosing storage (optional)** By default a new project's files are provisioned in your organization's default cloud storage. To place the project's primary folder elsewhere, include an optional `storage` object on the create payload: | Field | Type | Description | | --------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `driveId` | UUID | The storage drive to use (see `GET /storage-drives`). | | `mode` | enum | `CREATE_NEW` — create a new folder under `path`; `USE_EXISTING` — attach the folder that already exists at `path`. | | `path` | string | For `CREATE_NEW`, the parent folder the new folder is created under; for `USE_EXISTING`, the folder itself. Ignored when `driveId` is the default cloud drive (the org's project root is always used). | | `name` | string | Optional folder name (`CREATE_NEW` only). | Omit the `storage` object entirely to use the default cloud location. Each project has exactly one primary folder at creation; attach additional folders afterward via `POST /projects/{id}/storage-folders` (see Storage folders). ```bash curl -X POST "$LA_BASE/api/v1/projects" \ -H "Authorization: ApiKey $LA_KEY" \ -H "Content-Type: application/json" \ -d '{ "code": "OPLAB", "name": "Operations Lab", "description": "Ops experiments for FY26.", "visibility": "PROTECTED", "storage": { "driveId": "1b9d6bcd-bbfd-4b2d-9b5d-ab8dfbbd4bed", "mode": "CREATE_NEW", "path": "/projects", "name": "Operations Lab" } }' ``` **Choosing an ELN notebook (optional)** If your organization has a connected Electronic Lab Notebook (ELN), you can link the new project to an existing notebook folder at creation time. Each platform has its own block; include the one matching your integration. Omit both to leave ELN provisioning off. The folder must already exist — the API links it as the project's primary notebook folder, it does not create a new one. Benchling — `benchling` object: | Field | Type | Description | | --------------- | ------ | ---------------------------------------------------------------------- | | `integrationId` | UUID | The Benchling integration to use (see `GET /integrations`). | | `folderId` | string | The Benchling folder to link as the project's primary notebook folder. | CDD Vault — `cddVault` object (CDD Vault has no nested folders, so you link an existing project container): | Field | Type | Description | | --------------- | ------ | ----------------------------------------------------------- | | `integrationId` | UUID | The CDD Vault integration to use (see `GET /integrations`). | | `projectId` | number | The CDD Vault project (container) to link. | ```bash curl -X POST "$LA_BASE/api/v1/projects" \ -H "Authorization: ApiKey $LA_KEY" \ -H "Content-Type: application/json" \ -d '{ "code": "OPLAB", "name": "Operations Lab", "description": "Ops experiments for FY26.", "visibility": "PROTECTED", "benchling": { "integrationId": "3f1a2b4c-5d6e-4f70-8a91-2b3c4d5e6f70", "folderId": "lib_abc123" } }' ``` **Choosing a default Git group (optional)** If your organization has a connected GitLab integration, you can give the project a default Git group via a `defaultGitGroup` object on create/update. It is a convenience pre-fill only: when Git repositories are created for studies or assays under this project, this group is pre-selected — callers may always choose a different group, and **no repository is created for the project itself**. Omit it for no default. | Field | Type | Description | | --------------- | ------ | ------------------------------------------------------------------------------------- | | `integrationId` | UUID | The GitLab integration the group belongs to (see `GET /integrations`). | | `groupId` | string | The id of the Git group to use as the default, as it appears in your GitLab instance. | A stored default that no longer resolves (group removed, integration disconnected) is simply ignored when pre-filling — it never blocks repository creation. *** #### Studies Studies belong to projects and group together related experiments. | Method | Path | Description | Auth | | ------ | -------------------------------------------- | ---------------------------------------------------------- | ----------------------------- | | GET | `/studies` | Paginated list of studies visible to the caller. | Member | | GET | `/studies/{id}` | Fetch a single study. | Member | | POST | `/studies` | Create a new study under a project. | Contributor on parent project | | PUT | `/studies/{id}` | Update study fields. | Contributor | | POST | `/studies/{id}/status` | Change status. Body: `{"status": "COMPLETE"}`. | Contributor | | POST | `/studies/{id}/archive?archived=true\|false` | Archive or restore. | Contributor | | PATCH | `/studies/{id}/move` | Move to a different project. Body: `{"projectId": "..."}`. | Contributor on both projects | | DELETE | `/studies/{id}` | Delete the study. | Contributor | **Create example** ```bash curl -X POST "$LA_BASE/api/v1/studies" \ -H "Authorization: ApiKey $LA_KEY" \ -H "Content-Type: application/json" \ -d '{ "name": "Cell viability screen", "description": "12-point dose response.", "projectId": "b1d1b15a-19e0-4d6f-8d33-7a3d3aef6cba", "status": "ACTIVE", "startDate": "2026-05-10" }' ``` **Study status values**: `CREATED`, `INITIALIZING`, `INITIALIZATION_FAILED`, `ACTIVE`, `COMPLETE`, `ON_HOLD`, `DEACTIVATED`. **Choosing an ELN notebook (optional)** If the parent project is linked to an ELN, you can provision notebook content for the study at creation time. Unlike a project (which links an existing folder), a study inherits the project's ELN integration and gets its own child content. Omit both fields to leave ELN provisioning off. Benchling — `benchling` object: creates a notebook folder under the project's Benchling folder and a notebook entry in it. | Field | Type | Description | | ---------------- | ------ | -------------------------------------------------------------------------- | | `templateId` | string | Optional Benchling entry template to apply. Omit for a blank entry. | | `templateFields` | object | Optional field values for the chosen template (`{ "Field name": value }`). | CDD Vault — `useCddVault` boolean: when `true`, creates a notebook entry under the project's CDD Vault container. CDD Vault has no nested folders, so there is nothing else to configure per study. ```bash curl -X POST "$LA_BASE/api/v1/studies" \ -H "Authorization: ApiKey $LA_KEY" \ -H "Content-Type: application/json" \ -d '{ "name": "Cell viability screen", "description": "12-point dose response.", "projectId": "b1d1b15a-19e0-4d6f-8d33-7a3d3aef6cba", "benchling": { "templateId": "tmpl_abc123", "templateFields": { "Owner": "Jane Doe" } }, "useCddVault": false }' ``` *** #### Assays Assays are the lowest-level experimental unit; each assay belongs to one study and has a defined assay type. | Method | Path | Description | Auth | | ------ | ------------------------------------------- | -------------------------------------------------------------------------------- | --------------------------- | | GET | `/assays` | Paginated list of assays visible to the caller. | Member | | GET | `/assays/{id}` | Fetch a single assay. | Member | | POST | `/assays` | Create a new assay under a study. Body must include `studyId` and `assayTypeId`. | Contributor on parent study | | PUT | `/assays/{id}` | Update assay fields. | Contributor | | POST | `/assays/{id}/status` | Change status. | Contributor | | POST | `/assays/{id}/archive?archived=true\|false` | Archive or restore. | Contributor | | PATCH | `/assays/{id}/move` | Move to a different study. Body: `{"studyId": "..."}`. | Contributor on both studies | | DELETE | `/assays/{id}` | Delete the assay. | Contributor | **Create example** ```bash curl -X POST "$LA_BASE/api/v1/assays" \ -H "Authorization: ApiKey $LA_KEY" \ -H "Content-Type: application/json" \ -d '{ "name": "Plate 1", "description": "MTT readout.", "studyId": "f4a01b78-...", "assayTypeId": "8b2c3d4e-...", "status": "ACTIVE", "startDate": "2026-05-12" }' ``` **Choosing an ELN notebook (optional)** If the assay's project is linked to an ELN, you can provision notebook content for the assay at creation time. Like a study, an assay inherits the project's ELN integration and gets its own child content. Omit both fields to leave ELN provisioning off. Benchling — `benchling` object: creates a notebook folder under the parent study's Benchling folder and a notebook entry in it. | Field | Type | Description | | ---------------- | ------ | -------------------------------------------------------------------------- | | `templateId` | string | Optional Benchling entry template to apply. Omit for a blank entry. | | `templateFields` | object | Optional field values for the chosen template (`{ "Field name": value }`). | CDD Vault — `useCddVault` boolean: when `true`, creates a notebook entry under the project's CDD Vault container. CDD Vault has no nested folders, so there is nothing else to configure per assay. ```bash curl -X POST "$LA_BASE/api/v1/assays" \ -H "Authorization: ApiKey $LA_KEY" \ -H "Content-Type: application/json" \ -d '{ "name": "Plate 1", "description": "MTT readout.", "studyId": "f4a01b78-...", "assayTypeId": "8b2c3d4e-...", "startDate": "2026-05-12", "benchling": { "templateId": "tmpl_abc123", "templateFields": { "Owner": "Jane Doe" } }, "useCddVault": false }' ``` *** #### Notes Notes are free-text annotations attached to a project, study, assay, or your organization. The v1 API exposes the current content of a note; full version history is internal-only. **Note endpoints are read-only on the public API** — create, update, and archive are performed through the Lab Atlas web UI. | Method | Path | Description | | ------ | ---------------------------------- | --------------------------------- | | GET | `/projects/{projectId}/notes` | List notes on a project. | | GET | `/projects/{projectId}/notes/{id}` | Fetch a single note. | | GET | `/studies/{studyId}/notes` | List notes on a study. | | GET | `/studies/{studyId}/notes/{id}` | Fetch a single note. | | GET | `/assays/{assayId}/notes` | List notes on an assay. | | GET | `/assays/{assayId}/notes/{id}` | Fetch a single note. | | GET | `/organization-notes` | List notes on your organization. | | GET | `/organization-notes/{id}` | Fetch a single organization note. | Archived notes are not returned by either the list or get-by-id endpoints. The id returned by a list is the note's id and resolves directly via the matching get-by-id endpoint. **Note representation** A note's `type` is one of `NOTE`, `COMMENT`, `CONCLUSION`, `TEMPLATE`; its `format` is one of `TIPTAP`, `MARKDOWN`, `TEXT`, `QUILL`. The `content` field holds the current version's body. *** #### Tasks Tasks are checklist items attached to a project, study, or assay. | Method | Path | Description | | ------ | ----------------------------------------------- | -------------------------------------------------------- | | GET | `/projects/{projectId}/tasks` | List tasks. | | GET | `/projects/{projectId}/tasks/{taskId}` | Fetch a single task. | | POST | `/projects/{projectId}/tasks` | Add a task. | | PUT | `/projects/{projectId}/tasks/{taskId}` | Update a task. | | PATCH | `/projects/{projectId}/tasks/{taskId}/complete` | Mark a task complete. Optional body for completion data. | | DELETE | `/projects/{projectId}/tasks/{taskId}` | Remove a task. | | GET | `/studies/{studyId}/tasks` | List tasks. | | GET | `/studies/{studyId}/tasks/{taskId}` | Fetch a single task. | | POST | `/studies/{studyId}/tasks` | Add a task. | | PUT | `/studies/{studyId}/tasks/{taskId}` | Update a task. | | PATCH | `/studies/{studyId}/tasks/{taskId}/complete` | Mark a task complete. Optional body for completion data. | | DELETE | `/studies/{studyId}/tasks/{taskId}` | Remove a task. | | GET | `/assays/{assayId}/tasks` | List tasks. | | GET | `/assays/{assayId}/tasks/{taskId}` | Fetch a single task. | | POST | `/assays/{assayId}/tasks` | Add a task. | | PUT | `/assays/{assayId}/tasks/{taskId}` | Update. | | PATCH | `/assays/{assayId}/tasks/{taskId}/complete` | Mark complete. | | DELETE | `/assays/{assayId}/tasks/{taskId}` | Remove. | **Task input body** ```json { "label": "QC the raw data", "status": "TODO", "dueDate": "2026-05-20", "assignedToId": "73c1d4f2-..." } ``` Status values: `TODO`, `IN_PROGRESS`, `COMPLETE`, `INCOMPLETE`. *** #### External links External links are URL references attached to a project, study, or assay. | Method | Path | Description | | ------ | ----------------------------------------------- | -------------------- | | GET | `/projects/{projectId}/external-links` | List links. | | GET | `/projects/{projectId}/external-links/{linkId}` | Fetch a single link. | | POST | `/projects/{projectId}/external-links` | Add a link. | | PUT | `/projects/{projectId}/external-links/{linkId}` | Update. | | DELETE | `/projects/{projectId}/external-links/{linkId}` | Remove. | | GET | `/studies/{studyId}/external-links` | List links. | | GET | `/studies/{studyId}/external-links/{linkId}` | Fetch. | | POST | `/studies/{studyId}/external-links` | Add. | | PUT | `/studies/{studyId}/external-links/{linkId}` | Update. | | DELETE | `/studies/{studyId}/external-links/{linkId}` | Remove. | | GET | `/assays/{assayId}/external-links` | List links. | | GET | `/assays/{assayId}/external-links/{linkId}` | Fetch. | | POST | `/assays/{assayId}/external-links` | Add. | | PUT | `/assays/{assayId}/external-links/{linkId}` | Update. | | DELETE | `/assays/{assayId}/external-links/{linkId}` | Remove. | **External-link input body** ```json { "label": "Vendor data sheet", "url": "https://supplier.example.com/cat/AB12345.pdf" } ``` *** #### Collaborators Collaborators model the external organizations (CROs, partner labs, vendors) you work with. They are organization-scoped — every collaborator belongs to one Lab Atlas organization. | Method | Path | Description | | ------ | --------------------- | ---------------------------- | | GET | `/collaborators` | Paginated list. | | GET | `/collaborators/{id}` | Fetch a single collaborator. | | POST | `/collaborators` | Create. | | PUT | `/collaborators/{id}` | Update. | | DELETE | `/collaborators/{id}` | Remove. | **Collaborator input body** ```json { "label": "Acme CRO", "organizationName": "Acme Contract Research", "organizationLocation": "Boston, MA", "contactPersonName": "Jane Doe", "contactEmail": "jane.doe@acme.example.com", "code": "ACME", "active": true } ``` *** #### Teams Teams are reusable groups of organization users that can be granted access to projects in one step. **Team writes require `ORGANIZATION_ADMIN`.** | Method | Path | Description | Auth | | ------ | ------------------- | --------------------------------------------------- | ------ | | GET | `/teams` | Paginated list. | Member | | GET | `/teams/{id}` | Fetch a team. | Member | | POST | `/teams` | Create a team. | Admin | | PUT | `/teams/{id}` | Update name, description, active flag, member list. | Admin | | POST | `/teams/{id}/users` | Add users. Body: `{"userIds": ["...", "..."]}`. | Admin | | DELETE | `/teams/{id}/users` | Remove users. Body: `{"userIds": [...]}`. | Admin | *** #### Keywords Keywords are simple tag strings shared across an organization. | Method | Path | Description | | ------ | ---------------- | ---------------------------------- | | GET | `/keywords` | Paginated list. | | GET | `/keywords/{id}` | Fetch a keyword. | | POST | `/keywords` | Create. Body: `{"value": "AKT1"}`. | Keyword values are case-sensitive and must be unique within an organization. *** #### Assay types Assay types define the metadata schema (fields and standard tasks) for assays. **Assay-type writes require `ORGANIZATION_ADMIN`.** | Method | Path | Description | Auth | | ------ | -------------------------- | ---------------------------------------------------------- | ------ | | GET | `/assay-types` | Paginated list. | Member | | GET | `/assay-types/{id}` | Fetch a single assay type, including its fields and tasks. | Member | | POST | `/assay-types` | Create. | Admin | | PUT | `/assay-types/{id}` | Update. | Admin | | POST | `/assay-types/{id}/status` | Change status. Body: `{"status": "ACTIVE"}`. | Admin | | DELETE | `/assay-types/{id}` | Delete. | Admin | Status values: `DRAFT`, `ACTIVE`, `INACTIVE`, `ARCHIVED`, `DELETED`. *** #### Study collections Study collections are named groupings of studies, useful for ad-hoc reporting or cross-project comparisons. | Method | Path | Description | | ------ | ------------------------------------------- | ------------------------------------------------- | | GET | `/study-collections` | List collections visible to the caller. | | GET | `/study-collections/{id}` | Fetch a single collection (includes its studies). | | POST | `/study-collections` | Create. | | PUT | `/study-collections/{id}` | Update name/description/visibility. | | DELETE | `/study-collections/{id}` | Delete. | | POST | `/study-collections/{id}/studies/{studyId}` | Add a study to the collection. | | DELETE | `/study-collections/{id}/studies/{studyId}` | Remove a study from the collection. | **Create body** ```json { "name": "Q2 hit follow-up", "description": "Studies tracking validated hits from Q1.", "visibility": "PROTECTED" } ``` *** #### Study relationships Study relationships record links between studies — e.g. "is parent of", "is blocked by", "is related to". | Method | Path | Description | | ------ | --------------------------------------------------- | ---------------------------------------------------- | | GET | `/studies/{studyId}/relationships` | List relationships originating from the given study. | | POST | `/studies/{studyId}/relationships` | Create a new relationship. | | DELETE | `/studies/{studyId}/relationships/{relationshipId}` | Remove a relationship. | **Create body** ```json { "type": "IS_RELATED_TO", "targetStudyId": "73c1d4f2-..." } ``` Relationship types: `IS_RELATED_TO`, `IS_PARENT_OF`, `IS_CHILD_OF`, `IS_BLOCKING`, `IS_BLOCKED_BY`, `IS_PRECEDED_BY`, `IS_SUCCEEDED_BY`. When you create a relationship, the inverse relationship is automatically created on the target study. *** #### Activity Activity records describe events that have happened in the organization — study status changes, assay creation, note edits, and so on. Activity is **read-only**; events are generated by Lab Atlas itself as side effects of other API calls. Visibility follows the same rules as the underlying resources: a caller can only see activity for projects, studies, and assays they are allowed to view. Cross-organization lookups return `404`. | Method | Path | Description | | ------ | ----------------------------------- | --------------------------------------------------- | | GET | `/activity` | Paginated org-wide activity visible to the caller. | | GET | `/activity/{id}` | Fetch a single activity event by UUID. | | GET | `/projects/{id}/activity` | Activity scoped to a single project. | | GET | `/studies/{id}/activity` | Activity scoped to a single study. | | GET | `/assays/{id}/activity` | Activity scoped to a single assay. | | GET | `/organization-users/{id}/activity` | Activity performed by a specific organization user. | **Activity DTO shape** ```json { "id": "1f3e6c14-...", "eventType": "study.status_changed", "data": { "oldStatus": "ACTIVE", "newStatus": "COMPLETE" }, "date": "2026-05-06T14:32:11.000+00:00", "organizationId": "b1d1b15a-...", "projectId": "8b2c3d4e-...", "studyId": "f4a01b78-...", "assayId": null, "organizationUserId": "73c1d4f2-...", "user": { "id": "73c1d4f2-...", "organizationId": "b1d1b15a-...", "user": { /* UserDtoV1 */ }, "roles": ["ORGANIZATION_USER"], "status": "ACTIVE" } } ``` The `eventType` field is a dotted string (e.g. `study.created`, `assay.status_changed`, `note.updated`). The shape of `data` depends on the event type — treat it as an opaque map of strings to JSON values when consuming generically. **Filtering by category** `GET /activity` accepts an optional `category` parameter, repeatable or comma-separated, restricting results to one or more classifications: | Category | Covers | | ---------------- | --------------------------------------------------------------------------------------- | | `RESEARCH` | Work on a record — studies, assays, notes, task completion. | | `GOVERNANCE` | Access and visibility changes scoped to a record — team membership, visibility changes. | | `ADMINISTRATIVE` | Organization-level changes — invitations, role changes, integration connections. | ```bash curl -s "$LA_BASE/api/v1/activity?category=GOVERNANCE,ADMINISTRATIVE" \ -H "Authorization: ApiKey $LA_KEY" | jq . ``` Omit the parameter to receive every category the caller can see. *** #### Personal integrations Your own OAuth connections to external services. These endpoints only ever operate on integrations you own — there is no way to read or disconnect another user's, and an id belonging to someone else returns `404`. | Method | Path | Description | | ------ | ----------------------- | ----------------------------------------------------------------------- | | GET | `/me/integrations` | Paginated list of your active personal integration connections. | | GET | `/me/integrations/{id}` | Fetch one of your personal integrations. | | DELETE | `/me/integrations/{id}` | Disconnect. Stored credentials are deleted and the connection archived. | Disconnecting preserves any drives or folders the connection backed; it removes Lab Atlas's ability to reach them on your behalf. Organization integrations are read through `GET /integrations` instead, and are not modifiable through the public API. *** #### Storage folders Storage folders link a project, study, or assay to a folder on a connected storage drive. Each record can have several attached folders, one of which is the **primary** folder. `{folderId}` is the id of the attachment (the join record), not the underlying drive folder. Responses contain folder metadata only — the API never lists the folder's subfolders or files. | Method | Path | Description | | ------ | -------------------------------------------------- | ---------------------------------------------------- | | GET | `/projects/{projectId}/storage-folders` | List folders attached to a project. | | GET | `/projects/{projectId}/storage-folders/{folderId}` | Fetch a single attachment. | | POST | `/projects/{projectId}/storage-folders` | Attach an existing drive folder. Returns `201`. | | PATCH | `/projects/{projectId}/storage-folders/{folderId}` | Update the attachment (set as primary). | | DELETE | `/projects/{projectId}/storage-folders/{folderId}` | Detach the folder (the drive folder is left intact). | | GET | `/studies/{studyId}/storage-folders` | List folders attached to a study. | | GET | `/studies/{studyId}/storage-folders/{folderId}` | Fetch a single attachment. | | POST | `/studies/{studyId}/storage-folders` | Attach an existing drive folder. | | PATCH | `/studies/{studyId}/storage-folders/{folderId}` | Set as primary. | | DELETE | `/studies/{studyId}/storage-folders/{folderId}` | Detach. | | GET | `/assays/{assayId}/storage-folders` | List folders attached to an assay. | | GET | `/assays/{assayId}/storage-folders/{folderId}` | Fetch a single attachment. | | POST | `/assays/{assayId}/storage-folders` | Attach an existing drive folder. | | PATCH | `/assays/{assayId}/storage-folders/{folderId}` | Set as primary. | | DELETE | `/assays/{assayId}/storage-folders/{folderId}` | Detach. | All write operations require **contribute** permission on the parent project/study/assay. **Attach body** ```json { "driveId": "8b2c3d4e-...", "path": "/bucket/projects/CPA/Data" } ``` The folder at `path` must already exist on the drive. **Set-primary body** is `{"primary": true}`. *** #### Read-only resources The following resources are exposed for **reads only** in the public API. Create/update/delete must be performed through the Lab Atlas web UI. | Resource | Endpoints | | ---------------------- | ----------------------------------------------------------------- | | Users | `GET /users`, `GET /users/{id}` | | Organization users | `GET /organization-users`, `GET /organization-users/{id}` | | Integrations | `GET /integrations`, `GET /integrations/{id}` | | Storage drives | `GET /storage-drives`, `GET /storage-drives/{id}` | | Shared storage folders | `GET /shared-storage-folders`, `GET /shared-storage-folders/{id}` | *** ### Errors Errors are returned as a JSON envelope: ```json { "timestamp": "2026-05-06T14:32:11.000+00:00", "statusCode": 404, "error": "Not Found", "message": "Project not found: b1d1b15a-19e0-4d6f-8d33-7a3d3aef6cba", "path": "/api/v1/projects/b1d1b15a-19e0-4d6f-8d33-7a3d3aef6cba" } ``` For validation failures (`400`), additional fields are included describing each invalid field: ```json { "statusCode": 400, "error": "Bad Request", "message": "Validation failed", "details": "code: must not be blank; description: must not be blank", "path": "/api/v1/projects", "errors": [ { "field": "code", "message": "must not be blank" }, { "field": "description", "message": "must not be blank" } ] } ``` The `statusCode` field carries the HTTP status as an integer (separate from the per-resource `status` enum some response bodies carry). The `details` field is a one-line human-readable summary of all field violations — handy for log lines and quick triage; for programmatic handling, iterate `errors[]`. A request that authenticates successfully but is denied at the controller layer (e.g. an admin endpoint called by a non-admin key) returns `403 Forbidden` with an empty body. A request that targets a resource the caller cannot view returns `404 Not Found` rather than `403` — this avoids leaking the existence of records the caller has no business knowing about. *** ### OpenAPI / Swagger The full machine-readable specification is available at: * **Swagger UI**: `https://.labatlas.com/docs/swagger-ui` (select the **public-v1** group) * **OpenAPI JSON**: `https://.labatlas.com/docs/api-docs/public-v1` The Swagger UI is gated behind the same API-key check as the API itself — paste your key into the **Authorize** dialog (header name `X-API-KEY`) to try requests inline. If you generate client SDKs from the OpenAPI document, regenerate after each Lab Atlas release; field additions are backwards-compatible but new endpoints may appear. *** ### Support If you hit a bug, need an endpoint that isn't listed here, or want to raise a security concern, email **** and include: * The full URL of the failing request * The HTTP status code returned * The response body (with any sensitive data redacted) * A timestamp (UTC) so support can correlate against server logs * The **key id** portion of the API key in use (the `lak_xxxxxxxx` prefix is safe to share; never share the secret after the dot) # MCP Server Connecting AI tools to Lab Atlas using model context protocol (MPC) Lab Atlas exposes a **Model Context Protocol (MCP) server** so AI tools — Claude Code, claude.ai, and any other AI agent — can browse your projects, studies, assays, notes, and tasks the same way a human collaborator would. The MCP server reuses your existing Lab Atlas **API key** for authentication, so there's no separate signup, no OAuth dance, and no second password to manage. This guide walks through getting a key, connecting an AI tool, and using the tools the MCP server exposes. {% hint style="info" %} Lab Atlas MCP is currently available only to Enterprise customers. {% endhint %} {% hint style="warning" %} The MCP server is currently in beta. Endpoints and entities may change over time. {% endhint %} *** ### What MCP gives you Once you connect an AI tool to the Lab Atlas MCP server it can, on your behalf: * Find projects, studies, and assays you have access to. * Pull the latest content of any electronic-lab-notebook note — whether attached to a project, study, assay, or the organization itself. * Read the task list on a study or assay, including status and due dates. * Read the external links, collaborators, teams, keywords, and study collections in your organization. * See which integrations (S3, SharePoint, Benchling, GitLab, etc.) and storage drives are connected. It does **not** currently create, modify, or delete anything in this release. An agent can summarize, search, and cross-reference, but it cannot change your data. *** ### Prerequisites You need an API key. The MCP server uses the exact same key format as the Lab Atlas REST API, so if you already have one for scripting or integrations you can reuse it. To create one: 1. Sign in to your Lab Atlas tenant. 2. Click **Settings** in the sidebar. 3. Go to **API access → API keys**. 4. Click **New API Key**, give it a memorable name (e.g. `claude-code-laptop`), and pick a duration. 5. Copy the value from the modal. It looks like `lak_.`. **This is the only time the full value is shown** — store it somewhere safe. Any member of your organization can create a key — no admin role is required. The key inherits your user's permissions and is scoped to your organization. An agent connecting with your key can see exactly what you can see in the web UI, no more and no less. > If you do not see the **API access** section in Settings, the feature is not enabled for your tenant — contact your administrator. You also need the MCP server URL for your tenant. The path is always `/mcp` (eg. `https://.labatlas.com/mcp` ). *** ### Connect from Claude Code [Claude Code](https://claude.com/claude-code) is Anthropic's terminal-based AI assistant. It manages MCP servers via the `claude mcp` subcommand. ```bash export LABATLAS_API_KEY=lak_xxxxxxxx.xxxxxxxxxxxxxxxxxxxx claude mcp add --transport http labatlas \ https://your-tenant.labatlas.com/mcp \ --header "X-API-KEY: $LABATLAS_API_KEY" claude mcp list # Expect: labatlas ✓ connected ``` The `--transport http` flag selects the **Streamable HTTP** transport, which is what the Lab Atlas server speaks. The `--header` is forwarded with every request. After this, start a Claude Code session as you normally would (`claude`) and the `labatlas` tools will be available. Try: > "Use the labatlas mcp to list my projects." To remove or refresh the registration: ```bash claude mcp remove labatlas ``` *** ### Connect from claude.ai claude.ai (the web app) supports remote MCP servers via the **Connectors** panel. 1. Open **Settings → Connectors**. 2. Choose **Add custom connector** (the exact label may say "Add custom MCP server"). 3. Fill in: * **URL**: `https://your-tenant.labatlas.com/mcp` * **Transport**: HTTP / Streamable HTTP (whichever option the UI offers) * **Custom header**: name `X-API-KEY`, value `lak_xxxxxxxx.xxxxxxxxxxxxxxxxxxxx` 4. Save. The connector should report **Connected**. Once connected, the Lab Atlas tools appear in the tool picker for any conversation, including Projects. *** ### Connect from the Anthropic API If you are building your own agent against the Anthropic API, configure the MCP server in the `mcp_servers` array on the message request: ```json { "mcp_servers": [ { "type": "url", "url": "https://your-tenant.labatlas.com/mcp", "name": "labatlas", "authorization_token": "lak_xxxxxxxx.xxxxxxxxxxxxxxxxxxxx" } ] } ``` The Anthropic API forwards `authorization_token` as `Authorization: Bearer `. Lab Atlas does **not** accept bearer tokens for API key auth, so if the SDK you use does not let you set a custom header, use the explicit `Authorization: ApiKey ` form via a header field instead. Most SDKs support a `headers` map on the MCP server config: ```json { "mcp_servers": [ { "type": "url", "url": "https://your-tenant.labatlas.com/mcp", "name": "labatlas", "headers": { "X-API-KEY": "lak_xxxxxxxx.xxxxxxxxxxxxxxxxxxxx" } } ] } ``` *** ### Available tools The server registers **53 read-only tools** today, grouped by resource: | Resource | Tools | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Projects | `list_projects`, `get_project` | | Studies | `list_studies`, `get_study`, `list_studies_by_project` | | Assays | `list_assays`, `get_assay`, `list_assays_by_study` | | Assay types | `list_assay_types`, `get_assay_type` | | Notes | `list_organization_notes`, `list_project_notes`, `list_study_notes`, `list_assay_notes`, `get_organization_note`, `get_project_note`, `get_study_note`, `get_assay_note` | | Tasks | `list_project_tasks`, `list_study_tasks`, `list_assay_tasks`, `get_task` | | External links | `list_project_external_links`, `list_study_external_links`, `list_assay_external_links` | | Collaborators | `list_collaborators`, `get_collaborator` | | Teams | `list_teams`, `get_team` | | Keywords | `list_keywords`, `get_keyword` | | Study collections | `list_study_collections`, `get_study_collection` | | Study relationships | `list_study_relationships` | | Integrations | `list_integrations`, `get_integration` | | Storage drives | `list_storage_drives`, `get_storage_drive` | | Storage folders | `list_project_storage_folders`, `list_study_storage_folders`, `list_assay_storage_folders` | | Shared storage folders | `list_shared_storage_folders`, `get_shared_storage_folder` | | Organization users | `list_organization_users`, `get_organization_user` | | Users | `list_users`, `get_user` | | Activity | `list_activities`, `get_activity`, `list_activities_by_project`, `list_activities_by_study`, `list_activities_by_assay`, `list_activities_by_user` | Listing tools accept optional `page` (zero-indexed) and `size` (max 100) parameters. Look-up tools take a single UUID parameter. The response shape mirrors the JSON returned by the equivalent `GET /api/v1/...` endpoint — see the [REST API Reference](/developer-tools/rest-api-reference) for field-level docs. You normally do not pick tools by hand. Ask the agent for what you want and let it choose: > "Find every study tagged with the `metabolomics` keyword and summarize the most recent note on each." The agent will plan a call sequence like `list_keywords` → `list_studies` → `list_study_notes` → `get_study_note` and assemble the answer. *** ### Example prompts A few prompts that exercise the read surface: * *"List my active projects and tell me which ones have studies that were updated this week."* * *"In project CPA, summarize the open tasks across all studies and group by assignee."* * *"Pull the latest note from study TID-101 and extract the experimental conditions table."* * *"For every assay in study PPB-101, list its external links and check whether any point to deprecated tools."* * *"Show me which integrations are configured and what storage drives back the project CPA-100."* *** ### Privacy and scope * **Authentication.** Every request authenticates via your API key. The MCP server has no anonymous mode. * **Authorization.** The agent inherits *your* permissions. It cannot see anything you cannot see in the web UI. Cross-organization reads are not possible — the server rejects them with a 404-equivalent error. * **Audit.** Tool calls run as your user and are visible in the same activity feeds and integration audit logs that other API traffic produces. * **Data flow.** Tool responses are JSON. They leave Lab Atlas only over the same HTTPS channel that serves the REST API, and only as part of a response to a request your agent made. * **Revocation.** Revoking the API key in the **Account settings → API keys** tab takes effect immediately and stops the agent in mid-conversation if a request is in flight. If you are giving an agent access for a one-off task — say, a Claude Code session on a borrowed laptop — issue a short-lived key (one to seven days) instead of reusing your long-lived one. *** ### Troubleshooting **`SDK auth failed: HTTP 401: Invalid OAuth error response`** You're connecting with the older SSE transport, which Claude Code's SDK does not forward custom headers to. Use `--transport http` (the Streamable HTTP variant) as shown above. **`401 Unauthorized` on a tool call** The key is missing, malformed, revoked, or expired. Generate a fresh key and reconnect. **Tool returns "X not found"** The record is in another organization, or your user doesn't have view permission. The agent treats this as a normal "not found" — it is not a server error. **Tool list is empty** The MCP server is not enabled in your deployment. Ask your administrator to check the server's MCP configuration. **Connection seems slow on large pages** Tool list responses are paginated to a max of 100 items. Ask the agent to scope its queries (e.g. by project) rather than scanning the full org. For deeper issues, capture the agent's stderr or the Lab Atlas server logs and share them with your administrator.