Client API Documentation:
26.11 (in development)
- LabKey SQL now supports the IS DISTINCT FROM and IS NOT DISTINCT FROM operators for null-safe comparisons: unlike = and !=, two NULLs are considered equal, so these are safe to use when a comparison might involve NULL values.
- Deprecated: using ${rLabkeySessionId} in a pipeline or transform script to authenticate via a session cookie. It still works, but new scripts should use ${apikey} instead.
26.7
- Python API: a new 'import_rows()' method provides fast bulk row import, instead of inserting rows one at a time. (docs)
- Python API: the 'Run' object now accepts a 'workflow_task' property, so an imported assay run can be associated with a workflow task programmatically. (docs)
- API keys can now be restricted to a specific security role (for example, Reader or Editor), useful for limiting what an AI agent, tool, or script can do with a given key.
- New MCP-Enabled SQL Access: AI agents connected to the MCP Server can query any schema or table the authenticated user has permission to access, using the new 'executeSQL' tool. Results still respect existing container and row-level permissions.
- New built-in queries expose all Reports, Custom Views, and Custom Queries on the site via the Schema Browser and standard query access, making it easier to audit and clean these up programmatically.
- 'getUsersWithPermissions()' (Java API) no longer supports the 'inactive' or 'includeInactive' flags.
- 'user-getUsers.api' now requires administrator permissions and returns all matching users, rather than only "project users" — a concept that no longer applies now that "project users" is redefined as users with read permission in the current folder or project, rather than members of a project group.
- Actions that execute mutating SQL (INSERT, UPDATE, DELETE, etc.) triggered via GET requests are no longer allowed in production deployments; this was previously enforced only in dev mode. If you have a script or integration that calls a LabKey action via GET to make changes, switch it to POST. A deprecated feature flag can temporarily restore the old behavior if you rely on an action that hasn't been migrated yet.
26.3
- Client APIs can now query and update samples using the RowId value; using the LSID value is no longer required.
- Workflow-related tables have been moved from the sampleManagement schema to a new workflow schema (effective as of 26.1). Update any custom LabKey SQL queries or reports that reference these tables directly.
- Improved lineage querying: search the lineage object for all ancestors and descendants in a single query.
- ${containerFilterName} has been added as a substitution marker in URL properties.
- API calls now default to detailed audit behavior.
25.11
- New 'moveRows' API to move list rows to other folders or projects. (docs)
- 'security-bulkUpdateGroup.api' now requires the caller to use the project that owns the group; Site Administrators can no longer perform these updates from the root container.
- Detailed audit logging is now automatically enabled for Samples, Sources, Data Classes, and Assay Data, so actions taken via Client APIs are fully tracked.
- API callers can no longer reduce the audit level below the effective default or the administrator-configured value.
25.7
- Lookup resolution has improved for values that look like numbers: LabKey now attempts to resolve by alternate key first (if allowLookupByAlternateKey is enabled), then by primary key.
- When lookup validation is off and allowLookupByAlternateKey is enabled, a missing lookup value now results in an error instead of silently resolving to null. A deprecated feature flag can restore the previous behavior if needed.
- The R assay transformation script example was updated to show proper encoding of strings: use the quote=TRUE and qmethod="double" parameters with write.table. Review any similar custom R scripts you maintain.
- Rlabkey 3.4.3 released. (docs)
- A new example of using the lineage API from Python was added. (docs)
25.3
- Rlabkey 3.4.1 released, supporting more consistent encoding of WebDAV URLs. This version requires LabKey 24.12 or higher; if you're on an earlier LabKey version (including 24.11), stay on Rlabkey 3.4.0 or lower. (docs)
- WebDAV URL encoding is now more consistent generally. If your scripts or integrations depend on the previous encoding behavior for file or API access, you may need to update them.
- LabKey SQL now supports precision and scale for NUMERIC values, as well as @format annotations.
24.11
- Rlabkey 3.4.0 released. (docs)
- You can now include a description when generating an API key, making it easier to track what each key is used for.
- Client API calls that provide credentials and fail authentication are rejected outright with a detailed error message, rather than silently continuing as an unauthenticated user.
- Support for bitmask (integer) permissions has been removed (deprecated in 24.7). Code that inspects bitmask permissions returned by APIs should switch to inspecting permission class alternatives.
- New documentation was added to help you determine which packages and versions are installed for R and Python.
24.7
- Client API calls that provide credentials and fail authentication are now rejected outright with a detailed error message, rather than silently continuing as an unauthenticated user. This is especially helpful when credentials are correct but expired or don't meet password complexity requirements.
- Support for bitmask (integer) permissions has been deprecated (removed in 24.11); code that inspects bitmask permissions returned by APIs should begin switching to permission class alternatives.
- Support for the Remote Login API has been deprecated (removed in 25.3).
