roboto.api_version

Module Contents

class roboto.api_version.RobotoApiVersion

Bases: roboto.compat.StrEnum

Enumeration of supported Roboto API versions.

This enum defines the available API versions for the Roboto platform. Each version represents a specific date-based API version that may include breaking changes, new features, or deprecations compared to previous versions.

API versions follow the YYYY-MM-DD format and are used to ensure backward compatibility while allowing the platform to evolve. Clients should specify the API version they were designed for to ensure consistent behavior.

is_latest()

Check if this API version is the latest available version.

Returns:

True if this version matches the latest API version, False otherwise.

Return type:

bool

static latest()

Get the latest available API version.

Returns:

The most recent API version supported by the platform.

Return type:

RobotoApiVersion

v2025_01_01 = '2025-01-01'

v2025_07_14 = '2025-07-14'

v2026_01_02 = '2026-01-02'

Release date for v0.35.0 of the Roboto Python SDK

v2026_02_02 = '2026-02-02'

Content mode introduced for query APIs.

v2026_02_11 = '2026-02-11'

path_in_schema is now a required field on AddMessagePathRequest

v2026_03_13 = '2026-03-13'

Query endpoints are now eventually consistent when using v2026_03_13 or later. Clients on older API versions maintain strong consistency for backward compatibility.

v2026_05_20 = '2026-05-20'

AgentSession and AI Chat are renamed to AgentThread across the SDK and REST API: chat_id / session_id become thread_id on the wire, /v1/ai/chats becomes /v1/ai/threads, and agent invoke becomes launch (POST /v1/ai/agents/{id}/launch; the previous developer-only …/invoke URL was removed outright). Clients on older API versions continue to receive session_id in response bodies and can keep calling the legacy /v1/ai/chats paths, which are soft-deprecated aliases on the same handlers.

v2026_07_05 = '2026-07-05'

PUT /v1/files/upload/<id>/progress responds with {uri, file_id} pairs instead of a bare file-id list, so upload clients can tell which created file belongs to which uploaded path. Clients on older API versions continue to receive the bare id list.

v2026_08_10 = '2026-08-10'

GET /v1/datasets/tags, GET /v1/events/tags, and GET /v1/files/tags respond with a paginated {items, next_token} object (with optional search/limit/page_token query parameters) instead of a bare string list, so tag autocomplete scales past the unique-tag cap. Clients on older API versions continue to receive the bare list.

v2026_08_27 = '2026-08-27'

/v1/triggers speaks the v2 trigger shape (events/once_per/targets from roboto.domain.triggers) instead of the legacy causes/for_each/action-column shape, and rejects a caller-supplied service_user_id. Clients on older API versions keep the legacy shape: their creates and updates are translated onto v2 triggers, responses are projected back, and triggers with no legacy representation (multiple targets, non-action targets, new event types) are filtered from lists and 404 on direct reads.

v2026_09_30 = '2026-09-30'

what the user was viewing when they sent the message, stored on the message itself. Clients on older API versions receive threads with those blocks removed, since their AgentContent union cannot parse them.

Type:

Agent thread messages can carry client_context content blocks

v2026_10_02 = '2026-10-02'

fs_type "link" and a roboto:// uri pinning one version of another file. Clients on older API versions, whose FSType has only file and directory, never receive one: links are dropped from file listings, and reading one directly by ID or path reports it as not found.

Type:

A file record can be a link