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

[langfuse-bot]

Confidence Score: 5/5

The PR appears safe to merge with no actionable correctness, security, or repository-rule issues identified.

Summary

• Adds object_start_time to synchronous and asynchronous comment creation APIs and the corresponding request model.
• Adds start_time to synchronous and asynchronous legacy observation lookup APIs.
• Serializes the observation hint as the optional startTime query parameter.

[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]

Looks good — a straightforward Fern-generated client update adding an optional performance-hint datetime parameter to two endpoints.

• Checked parameter threading: object_start_time/start_time flow correctly from public CommentsClient.create/ObservationsV1Client.get into the raw clients.
• Checked serialization: comments passes objectStartTime as a body field (via omit), observations serializes startTime via serialize_datetime only when non-None, matching existing patterns in the file.
• Checked the new CreateCommentRequest pydantic field is correctly typed/optional and mirrors the raw client parameter.
• The "never changes the result" docstring wording was already considered and ruled out as a concern for this run.

Extended reasoning...

Overview

This PR is an auto-generated (Fern) API client update touching five files: the comments client/raw_client/pydantic request model, and the legacy observations_v1 client/raw_client. It adds a single new optional datetime parameter to two existing endpoints (CommentsClient.create and ObservationsV1Client.get, plus their async and raw counterparts), threading the value through to either the JSON request body (comments) or the query string via serialize_datetime (observations).

Security risks

None identified. The new parameter is a plain optional datetime that is either omitted from the request body or serialized into a query string parameter using the existing serialize_datetime helper already used elsewhere in the codebase. There is no new auth, deserialization, or injection surface — the datetime is client-supplied and passed through to a trusted first-party API endpoint using established serialization utilities.

Level of scrutiny

Given this is boilerplate generated client code (explicitly marked as Fern-generated) making a small, additive, and mechanical change — adding one optional parameter and correctly wiring it through existing patterns (OMIT semantics for body fields, conditional serialize_datetime for query params) — a light level of scrutiny is appropriate. I verified the parameter threading and serialization by reading the full diff of both raw_client.py files directly rather than relying solely on the automated summary.

Other factors

The bug hunting system found no issues, and the one candidate issue that was surfaced (the docstring's "never changes the result" wording for a stated performance-only hint) was already investigated and ruled out in this run. The change is small, self-contained, follows the exact pattern used by other optional/hint parameters in this same generated codebase, and does not touch any critical or security-sensitive code path.