SDK reference

The reference is organized around the objects an application uses at runtime. Signatures show the stable public shape; behavior sections explain durability, scope, side effects, and failure modes.

Core client

• Client and configuration — createViby, VibyConfig, user scope, workers, storage, models, skills, and shutdown.
• Chats and projects — create, import, search, update, delete, restore, messages, project environments, and history.
• Generations and events — start, stream, wait, cancel, retry, resume, tasks, artifacts, outbound delivery, and workers.
• Versions and artifacts — source inspection, immutable changes, iteration, restore, fork, preview, evaluation, push, deploy, and download.

Optional capabilities

• Previews and sandboxes — sessions, leases, command policy, process readiness, reconnect, and cleanup.
• Tool sources — static tools, durable registrations, per-chat selection, authorization, permission policy, and redaction.
• Integrations — provider-neutral repository and deployment connections plus durable effect history.

Hosting and compatibility

• Web API host — all framework-neutral HTTP routes and the typed Web client.
• Errors — stable error families and safe handling guidance.
• Package entry points — portable core, Node client, providers, optional peers, and conformance suites.
• Complete v1 contract — normative persistence and lifecycle details in one page.

Reading the reference

All resource IDs are opaque strings. All timestamps returned by the direct TypeScript client are Date objects. Cursor values are opaque strings and must be stored and returned without parsing. Methods that contact a model, sandbox, browser, tool server, repository, or deployment provider are server-side operations unless a product intentionally exposes them through its own authenticated API.

Every scoped operation enforces both tenantId and userId; a resource owned by another scope is reported as not found rather than revealed.