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

[langfuse-bot]

Greptile Summary

This is an auto-generated API spec update synced from langfuse/langfuse at cf53f2e. It updates JSDoc comments and TypeScript interface descriptions for blob storage integrations, dataset items, and scores endpoints.

• Scores v1 deprecation: Scores.getMany and Scores.get now carry explicit @deprecated notices directing users to GET /api/public/v3/scores.
• Scores v3 field groups: The fields parameter documentation is updated to clarify that core fields are always returned and only the supplemental groups (details, subject, annotation) should be passed — core is removed from the allowed values list.
• Blob storage field groups: exportFieldGroups is now documented as applicable to all export sources including LEGACY_TRACES_OBSERVATIONS, removing prior restrictions that required it to be null for that source.

Confidence Score: 4/5

Safe to merge with one caveat: removing core from the allowed fields values reflects a server-side contract change that could break callers who previously passed fields="core" explicitly.

Almost all changes are documentation-only clarifications. The one functional concern is in GetScoresV3Request.ts — core has been dropped from the documented allowed values for the fields parameter, and the surrounding text says unknown names return HTTP 400. If the server has actually begun rejecting core as an input, existing SDK users who explicitly pass it will start receiving 400 errors with no other code change on their end.

packages/core/src/api/api/resources/scoresV3/client/requests/GetScoresV3Request.ts — the removal of core from the allowed fields values deserves a second look to confirm backwards compatibility.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Client calls scores endpoint] --> B{Which API version?}
    B -- "v1 GET /api/public/scores" --> C[Scores.getMany / Scores.get\n⚠️ DEPRECATED — not available on v4+]
    B -- "v3 GET /api/public/v3/scores" --> D[ScoresV3.getManyV3]
    D --> E{fields param?}
    E -- "omitted" --> F[Returns core fields only]
    E -- "details / subject / annotation" --> G[Returns core + requested groups]
    E -- "core or unknown name" --> H[HTTP 400]
    G --> I[Response: id, projectId, name,\nvalue, dataType, source, timestamp,\nenvironment, createdAt, updatedAt\n+ optional groups]

Loading

Prompt To Fix All With AI

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

---

### Issue 1 of 1
packages/core/src/api/api/resources/scoresV3/client/requests/GetScoresV3Request.ts:14-15
**`core` removed from allowed `fields` values — may break existing callers**

The old JSDoc listed `core` as an allowed value (`Allowed: core, details, subject, annotation`); the new JSDoc removes it (`Allowed: details, subject, annotation`). Since the comment also says "Unknown names return HTTP 400", any SDK user who currently passes `fields: "core"` or `fields: "core,details"` will receive a `400` response after this spec update if the server-side has changed to match the new spec. This is a backwards-incompatible change for explicit callers and is not called out in the PR description.

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

Greptile also left 1 inline comment 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 12, 2026 12:21pm

[github-actions]

@claude review

[claude]

LGTM — auto-generated Fern types from API spec update; only doc-string changes, no logic.

Extended reasoning...

Overview

This PR is an auto-generated update of the Fern-generated TypeScript API client (packages/core/src/api/api/resources/...). All 8 modified files carry the This file was auto-generated by Fern from our API Definition header. The changes are exclusively docstring/JSDoc updates:

• Clarified BlobStorageExportFieldGroup / BlobStorageExportSource semantics (field groups now apply to all sources)
• Updated exportFieldGroups description on BlobStorageIntegrationResponse and CreateBlobStorageIntegrationRequest
• Added a 255-char limit note on CreateDatasetItemRequest.id
• Added deprecation notices to v2 scores.getMany and scores.getById pointing users to v3
• Expanded scoresV3 field-group documentation

No type signatures, runtime logic, request shapes, or endpoint URLs change.

Security risks

None. Documentation-only changes in auto-generated code; no auth, crypto, input handling, or network behavior is touched.

Level of scrutiny

Minimal. These files are regenerated by the Fern codegen pipeline whenever the upstream OpenAPI spec changes, so reviewing the JS side line-by-line is not meaningful — the source of truth is the spec in langfuse/langfuse@cf53f2e. The diff conforms to that automated pattern.

Other factors

The bug-hunting system found no issues, and there are no outstanding human reviewer comments. Vercel preview is building normally.

[greptile-apps]

core removed from allowed fields values — may break existing callers

The old JSDoc listed core as an allowed value (Allowed: core, details, subject, annotation); the new JSDoc removes it (Allowed: details, subject, annotation). Since the comment also says "Unknown names return HTTP 400", any SDK user who currently passes fields: "core" or fields: "core,details" will receive a 400 response after this spec update if the server-side has changed to match the new spec. This is a backwards-incompatible change for explicit callers and is not called out in the PR description.

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:
**`core` removed from allowed `fields` values — may break existing callers**

The old JSDoc listed `core` as an allowed value (`Allowed: core, details, subject, annotation`); the new JSDoc removes it (`Allowed: details, subject, annotation`). Since the comment also says "Unknown names return HTTP 400", any SDK user who currently passes `fields: "core"` or `fields: "core,details"` will receive a `400` response after this spec update if the server-side has changed to match the new spec. This is a backwards-incompatible change for explicit callers and is not called out in the PR description.

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