feat(api): update API spec from langfuse/langfuse 3bd4817

[langfuse-bot]

Generated from langfuse/langfuse main at 3bd4817.

Confidence Score: 4/5

The PR appears safe to merge, with non-blocking documentation fixes.

Summary

Adds organization-level LLM connection methods to the synchronous and asynchronous API clients.

• Python clients can manage organization-wide LLM connections.

_{Reviews (1) · Last reviewed commit: "feat(api): update API spec from langfuse..." · Reviewed by Greptile}

[github-actions]

@claude review

[claude]

Claude Code Review

No review was started: this request came from a bot account. Manual reviews can only be requested by someone with write access to this repository. Ask a maintainer to comment @claude review, or have your automation post the comment from a user account with write access.

_{Tip: disable this comment in your organization's Code Review settings.}

[claude]

LGTM. This is a Fern regeneration that adds org-level LLM connection methods, and they follow the existing project-level methods line for line.

What was reviewed:

• The existing sync and async list/upsert/delete methods still call api/public/llm-connections. The -/+ lines in raw_client.py come from diff realignment and don't change those paths.
• Each new *_organization method in raw_client.py (sync and async) uses the right HTTP verb and the api/public/organizations/llm-connections path. Delete puts the id in the path, and each method parses into PaginatedLlmConnections, LlmConnection or DeleteLlmConnectionResponse as appropriate.
• The upsert body uses the same camelCase keys as the project-level upsert (secretKey, baseURL, customModels, withDefaultModels, extraHeaders) and passes omit=OMIT. client.py hands all arguments straight through to the raw client.

Extended reasoning...

The change only touches the generated Fern clients in langfuse/api/llm_connections/ (client.py and raw_client.py). It adds three org-scoped methods each to the sync and async clients and their raw clients, and makes no other changes. The new code copies the existing project-level methods and changes only the URL path, so it has no new auth, crypto or data-handling logic. Authentication is still handled by the shared client wrapper. CODEOWNERS covers only .github/, nobody else has commented or reviewed, and the bug hunt finished normally (dry_streak) with no findings.

[greptile-apps]

New examples fail to import

The new examples import LangfuseAPI and AsyncLangfuseAPI from langfuse, but those classes are exported from langfuse.api. The upsert examples also import LlmAdapter from the nonexistent langfuse.llm_connections package. Copying these examples fails before sending a request.

Use from langfuse.api import LangfuseAPI (or AsyncLangfuseAPI) and from langfuse.api.llm_connections import LlmAdapter throughout the new examples.

Prompt To Fix With AI

This is a comment left during a code review.
Path: langfuse/api/llm_connections/client.py
Line: 288-289

Comment:
**New examples fail to import**

The new examples import `LangfuseAPI` and `AsyncLangfuseAPI` from `langfuse`, but those classes are exported from `langfuse.api`. The upsert examples also import `LlmAdapter` from the nonexistent `langfuse.llm_connections` package. Copying these examples fails before sending a request.

Use `from langfuse.api import LangfuseAPI` (or `AsyncLangfuseAPI`) and `from langfuse.api.llm_connections import LlmAdapter` throughout the new examples.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[greptile-apps]

Provider scope is unclear

The new upsert_organization documentation says provider must be unique in a project, although this method updates a connection shared across the organization. Users get conflicting guidance about which connection a repeated provider name updates.

Change this to organization-wide uniqueness in both clients and their raw counterparts.

Prompt To Fix With AI

This is a comment left during a code review.
Path: langfuse/api/llm_connections/client.py
Line: 256

Comment:
**Provider scope is unclear**

The new `upsert_organization` documentation says `provider` must be unique in a project, although this method updates a connection shared across the organization. Users get conflicting guidance about which connection a repeated provider name updates.

Change this to organization-wide uniqueness in both clients and their raw counterparts.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!