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

[langfuse-bot]

Greptile Summary

The PR synchronizes the observations-v2 model-name field with the updated API specification.

• Renames ObservationV2.provided_model_name to model.
• Updates synchronous and asynchronous observations client documentation to describe the new field name.

Confidence Score: 4/5

The public response-model rename should preserve the previous attribute before this PR is merged.

Existing users reading ObservationV2.provided_model_name will receive an AttributeError after upgrading because the field is removed outright rather than retained as a deprecated compatibility property.

Files Needing Attention: langfuse/api/commons/types/observation_v2.py

Prompt To Fix All With AI

### Issue 1
langfuse/api/commons/types/observation_v2.py:160
**Public model attribute removed**

When existing integrations upgrade and access `ObservationV2.provided_model_name`, the renamed model no longer exposes that public attribute, causing an `AttributeError` even though the same value remains available as `model`. Preserve a deprecated compatibility property or alias for the previous attribute.

---

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

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

Greptile also left 1 inline comment on this PR.

Context used:

• Knowledge Base — Generated API service domains
• Knowledge Base — Shared models and data serialization

[github-actions]

@claude review

[claude]

Approved: mechanical, auto-generated API-spec sync that renames one field.

What was reviewed: the ObservationV2.provided_model_name -> model rename in langfuse/api/commons/types/observation_v2.py, the matching docstring updates in langfuse/api/observations/client.py and raw_client.py, and consistency of the rename across the codebase. Checked that dropping the FieldMetadata(alias=...) annotation is correct here: since "model" has no camelCase/snake_case difference, no alias is needed (matches the pattern used by every other field in this generated file). Remaining providedModelName references in metrics/client.py, metrics/raw_client.py, and unstable/dashboard_widgets/client.py belong to a different, unrelated API surface (metrics filter fields), not this type, and are unaffected. Also confirmed protected_namespaces=() in UniversalBaseModel's config, so a field literally named model does not collide with pydantic's reserved model_ namespace.

Extended reasoning...

Overview

This PR is an auto-generated update (Fern codegen from the langfuse/langfuse OpenAPI spec) that renames ObservationV2.provided_model_name (aliased to JSON key providedModelName) to a plain model: typing.Optional[str] field with no alias, plus matching docstring text updates in the observations client/raw_client files. Three files changed, all generated code, no hand-written logic.

Security risks

None. No auth, crypto, permission, or input-handling logic is touched — this is purely a schema/type rename in a generated data model plus doc-string text.

Level of scrutiny

Low-to-moderate is appropriate given this is machine-generated boilerplate, but I still verified the rename is self-consistent: the removal of the FieldMetadata(alias="providedModelName") annotation is correct because the file's established convention (visible across every other field: trace_id->traceId, internal_model_id->internalModelId, etc.) only adds an alias when the snake_case Python name differs from the camelCase wire name. Since model has no case difference, omitting the alias is the right and consistent choice, implying the underlying API's JSON key for this field is now model rather than providedModelName. I also checked for stray/incomplete references to the old name elsewhere in the codebase; the only remaining providedModelName occurrences are in metrics/client.py, metrics/raw_client.py, and unstable/dashboard_widgets/client.py, which are string literals for a distinct metrics-query filter field, not part of ObservationV2 — those are correctly untouched.

Other factors

Confirmed UniversalBaseModel's model_config sets protected_namespaces=(), so naming the field model does not trigger a pydantic v2 protected-namespace warning/conflict. No test files were touched by this diff; that's expected for auto-generated SDK code synced from an upstream spec, and the bug hunter reported no findings.