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

[langfuse-bot]

Greptile Summary

This is an auto-generated API spec sync from langfuse/langfuse at commit d89dbc1, updating JSDoc comments across the blob-storage integration types and the v1/v3 scores clients.

• The scores v1 GET /scores and GET /scores/{scoreId} endpoints are marked deprecated in favour of GET /api/public/v3/scores, with a note that they are unavailable on Langfuse v4+.
• The v3 scores fields parameter comment is tightened: core is dropped from the allowed-values list (since it is now always returned), and each remaining group (details, subject, annotation) is described inline.
• The blob-storage exportFieldGroups semantics are updated to reflect that the field now applies to all export sources (previously, sending it for LEGACY_TRACES_OBSERVATIONS returned HTTP 400); the response-type comment is simplified but loses the explicit nullability note for that source.

Confidence Score: 3/5

Safe to merge for users on the latest server version, but existing clients explicitly passing fields: "core" to the v3 scores endpoint will start receiving HTTP 400 errors with no code change on their side.

The removal of core from the documented allowed values for the fields parameter—combined with the 'Unknown names return HTTP 400' contract—turns previously valid SDK usage into a runtime error. Any caller following the old documented default of fields: "core" will break silently after this update. The blob-storage nullability comment loss is lower-impact but also removes useful client-side guidance.

packages/core/src/api/api/resources/scoresV3/client/requests/GetScoresV3Request.ts (breaking fields contract) and packages/core/src/api/api/resources/blobStorageIntegrations/types/BlobStorageIntegrationResponse.ts (lost nullability guidance).

Sequence Diagram

sequenceDiagram
    participant Client as SDK Client
    participant API as Langfuse API

    Note over Client,API: Scores v1 (Deprecated on v4+)
    Client->>API: GET /api/public/v1/scores?...
    API-->>Client: 200 OK (v3 only) / unavailable on v4

    Note over Client,API: Scores v3 (fields parameter)
    Client->>API: "GET /api/public/v3/scores?fields=details,subject"
    API-->>Client: "200 OK {core always included + requested groups}"

    Client->>API: "GET /api/public/v3/scores?fields=core [OLD usage]"
    API-->>Client: 400 Bad Request (core now unknown group)

    Note over Client,API: Blob Storage Integration
    Client->>API: "POST /blob-storage-integrations {exportSource: LEGACY_TRACES_OBSERVATIONS, exportFieldGroups: [...]}"
    API-->>Client: 200 OK (previously returned 400 for this combination)

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
**Removing `core` from allowed `fields` values is a breaking change**

The previous JSDoc said `Allowed: core, details, subject, annotation`, and the Client.ts comment said the parameter defaults to `"core"`. SDK users who explicitly passed `fields: "core"` (or `"core,details"` etc.) were following the documented contract. Now that `core` is removed from the allowed list and the API returns HTTP 400 for unknown group names, those callers will start receiving 400 errors without any change on their end. A changelog note or a migration guide callout may be needed so users know to drop `core` from any explicit `fields` string they send.

### Issue 2 of 2
packages/core/src/api/api/resources/blobStorageIntegrations/types/BlobStorageIntegrationResponse.ts:24
**Nullability condition for `exportFieldGroups` is no longer documented**

The old comment explicitly stated that `exportFieldGroups` is `Always null when exportSource is LEGACY_TRACES_OBSERVATIONS`. With this change, only the "empty list = all groups" semantics are described, and there is no guidance on when the field remains `null`. Clients that branch on `exportFieldGroups == null` for `LEGACY_TRACES_OBSERVATIONS` (e.g. to skip rendering field-group selectors) may now silently receive a non-null array and render unexpected UI or produce incorrect logic. A brief note on when callers should still expect `null` would help.

_{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 11, 2026 11:16am

[github-actions]

@claude review

[claude]

LGTM — auto-generated API spec update with only doc-comment changes.

Extended reasoning...

Overview

This PR is an auto-generated Fern API spec update (d89dbc1) touching 7 files under packages/core/src/api/api/resources/. All diffs are comment-only changes: clarifications to JSDoc on BlobStorageExportFieldGroup, BlobStorageExportSource, BlobStorageIntegrationResponse, and CreateBlobStorageIntegrationRequest reflecting that exportFieldGroups now applies to all export sources; new **Deprecated.** notices on the v2 Scores.getMany/getById methods; and expanded documentation on the v3 scores endpoint and its fields query parameter. No types, signatures, query parameter handling, URLs, or runtime logic change.

Security risks

None. The diff modifies only JSDoc comments in generated client code. No auth, crypto, input validation, or network behavior is altered.

Level of scrutiny

Very low. These are doc-only edits in auto-generated Fern client files that the repository regenerates from the upstream OpenAPI spec. The bug-hunting system reported no findings, and a manual scan confirms every hunk is enclosed in /** ... */ blocks.

Other factors

The deprecation notes on v2 scores endpoints are informational only — the methods, URLs, and error handling are unchanged, so existing consumers continue to work. PR follows the same pattern as the prior auto-generated spec PRs in recent history (e.g. #821, #817).

[greptile-apps]

Removing core from allowed fields values is a breaking change

The previous JSDoc said Allowed: core, details, subject, annotation, and the Client.ts comment said the parameter defaults to "core". SDK users who explicitly passed fields: "core" (or "core,details" etc.) were following the documented contract. Now that core is removed from the allowed list and the API returns HTTP 400 for unknown group names, those callers will start receiving 400 errors without any change on their end. A changelog note or a migration guide callout may be needed so users know to drop core from any explicit fields string they send.

Prompt To Fix With AI

This is a comment left during a code review.
Path: packages/core/src/api/api/resources/scoresV3/client/requests/GetScoresV3Request.ts
Line: 14-15

Comment:
**Removing `core` from allowed `fields` values is a breaking change**

The previous JSDoc said `Allowed: core, details, subject, annotation`, and the Client.ts comment said the parameter defaults to `"core"`. SDK users who explicitly passed `fields: "core"` (or `"core,details"` etc.) were following the documented contract. Now that `core` is removed from the allowed list and the API returns HTTP 400 for unknown group names, those callers will start receiving 400 errors without any change on their end. A changelog note or a migration guide callout may be needed so users know to drop `core` from any explicit `fields` string they send.

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

Nullability condition for exportFieldGroups is no longer documented

The old comment explicitly stated that exportFieldGroups is Always null when exportSource is LEGACY_TRACES_OBSERVATIONS. With this change, only the "empty list = all groups" semantics are described, and there is no guidance on when the field remains null. Clients that branch on exportFieldGroups == null for LEGACY_TRACES_OBSERVATIONS (e.g. to skip rendering field-group selectors) may now silently receive a non-null array and render unexpected UI or produce incorrect logic. A brief note on when callers should still expect null would help.

Prompt To Fix With AI

This is a comment left during a code review.
Path: packages/core/src/api/api/resources/blobStorageIntegrations/types/BlobStorageIntegrationResponse.ts
Line: 24

Comment:
**Nullability condition for `exportFieldGroups` is no longer documented**

The old comment explicitly stated that `exportFieldGroups` is `Always null when exportSource is LEGACY_TRACES_OBSERVATIONS`. With this change, only the "empty list = all groups" semantics are described, and there is no guidance on when the field remains `null`. Clients that branch on `exportFieldGroups == null` for `LEGACY_TRACES_OBSERVATIONS` (e.g. to skip rendering field-group selectors) may now silently receive a non-null array and render unexpected UI or produce incorrect logic. A brief note on when callers should still expect `null` would help.

How can I resolve this? If you propose a fix, please make it concise.