feat(api): update API spec from langfuse/langfuse b8db8b6

[langfuse-bot]

Greptile Summary

This is an automated API spec sync from langfuse/langfuse@b8db8b6, updating TypeScript type definitions and JSDoc comments across the blob storage integration and scores resources — no runtime logic is changed.

• Scores v1 deprecation: GET /api/public/v1/scores (list and by-ID) are now marked deprecated in the JSDoc, directing users to v3; v3's field-group documentation was expanded to enumerate exactly which fields each group adds.
• Blob storage field groups: exportFieldGroups now applies to all export sources (including LEGACY_TRACES_OBSERVATIONS); a new Cloud-only integration deprecation gate (effective 2026-06-22) is added alongside the existing project-level gate.
• Minor additions: CreateDatasetItemRequest.id now documents the 255-character max length.

Confidence Score: 4/5

Safe to merge for documentation; one backward-incompatible parameter change warrants a changelog note.

The fields=core removal from the allowed values list in GetScoresV3Request is a subtle breaking change for any consumer who was passing core explicitly per the old spec — the server returns HTTP 400 for unknown group names.

packages/core/src/api/api/resources/scoresV3/client/requests/GetScoresV3Request.ts and packages/core/src/api/api/resources/blobStorageIntegrations/types/BlobStorageIntegrationResponse.ts

Sequence Diagram

sequenceDiagram
    participant SDK as JS SDK Consumer
    participant v1 as GET /v1/scores
    participant v3 as GET /v3/scores

    SDK->>v1: getMany() or get(scoreId)
    note over v1: Deprecated, not available on Langfuse v4+
    v1-->>SDK: scores response

    SDK->>v3: "getMany with fields=core"
    note over v3: core removed from allowed values
    v3-->>SDK: HTTP 400 unknown group name

    SDK->>v3: "getMany with fields=details,subject,annotation"
    note over v3: Core fields always returned automatically
    v3-->>SDK: scores with core plus requested groups

Loading

Prompt To Fix All With AI

Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
packages/core/src/api/api/resources/scoresV3/client/requests/GetScoresV3Request.ts:14-15
**`core` no longer listed as an allowed `fields` value**

The previous spec listed `core` as a valid group ("Allowed: core, details, subject, annotation"). The new spec drops it ("Allowed: details, subject, annotation"), and the comment still warns that "Unknown names return HTTP 400." Any existing SDK consumer who was passing `fields: "core"` explicitly will now get a 400 from the server after this update, which is a silent breaking change relative to what the previous docs promised.

### Issue 2 of 2
packages/core/src/api/api/resources/blobStorageIntegrations/types/BlobStorageIntegrationResponse.ts:24
**`exportFieldGroups` nullability semantics not fully clarified**

The old doc said "Always `null` when exportSource is `LEGACY_TRACES_OBSERVATIONS`". The new doc says "An empty list is treated as all groups during export" but does not explain when the field is `null` vs an empty array (`[]`). Consumers who branched on `null` to detect the `LEGACY_TRACES_OBSERVATIONS` case will no longer have a reliable signal, and the empty-array semantics overlap with "all groups" in a way that may surprise callers.

_{Reviews (1): Last reviewed commit: "feat(api): update API spec from langfuse..." | Re-trigger Greptile}

Greptile also left 2 inline comments on this PR.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
langfuse-js	Ready	Preview	Jun 15, 2026 10:15am

[github-actions]

@claude review

[claude]

Auto-generated API spec update — doc-only changes (deprecation notices, clarifications, character limit doc).

Extended reasoning...

Overview

This PR is an auto-generated Fern API spec update across 8 files in packages/core/src/api/api/resources/. Every change in the diff is a JSDoc/comment update — no type signatures, no enum values, no client logic, no endpoints added or removed. Touched areas: blob storage integration types (clarifying how exportFieldGroups now applies to all sources and documenting a new 2026-06-22 cloud deprecation gate), dataset item id (255-char limit note), v2 scores client (deprecation notices pointing to v3), and v3 scores client (expanded field-group documentation).

Security risks

None. All changes are to TypeScript doc comments in auto-generated client code; no runtime behavior, no auth/crypto/permissions code, no user input handling.

Level of scrutiny

Low. These are mechanical Fern-generated comment updates that mirror upstream spec changes. The only thing to verify is that no type/enum/signature drifted unexpectedly, which a quick scan of the diff confirms — only JSDoc lines changed.

Other factors

The bug hunting system found no issues. The PR follows the established feat(api): update API spec from langfuse/langfuse <sha> pattern used for routine spec syncs in this repo. No reviewer comments outstanding.

[claude]

LGTM — auto-generated API spec sync; only JSDoc/type comment changes, no runtime logic.

Extended reasoning...

Overview

This is an automated API spec sync from langfuse/langfuse@b8db8b6 regenerating Fern-generated TypeScript client files. All 8 changed files start with the This file was auto-generated by Fern header. The diff is purely JSDoc/comment updates plus a 255-char length note on CreateDatasetItemRequest.id. No runtime logic, no exported types, no enum values, and no method signatures change.

Security risks

None. There is no authentication, crypto, input validation, or network-facing logic touched. The changes are confined to documentation strings and a comment about a length constraint that the server enforces.

Level of scrutiny

Low. These files are codegen output, regenerated from the upstream OpenAPI spec; reviewing them by hand has limited value beyond confirming the diff is documentation-only. The only items worth checking are the two Greptile flags (P1 core removal, P2 exportFieldGroups nullability), both of which the maintainer (niklassemmler) already addressed inline confirming the server still accepts core and that no breaking change exists.

Other factors

The bug-hunting system found no bugs. The maintainer has already engaged with the only substantive feedback and resolved both inline threads. Nothing else in the diff is ambiguous or requires human judgment.