Runtime contract
The runtime contract supports opening or resuming a conversation, sending a message or structured interaction, receiving inline or streamed output, and reconciling history after reconnecting.
Conversation attachments
Attachments are uploaded to an open conversation before sending the message. The send request refers to the returned attachment identifiers, and persisted history and realtime message events return the files linked to each turn.
Current supported formats are PNG, JPEG, PDF, TXT, and LOG, subject to the server's size and per-message limits. Clients must use the server MIME type and status rather than trusting local filename extensions. An unlinked attachment can be deleted; an attachment already linked to a sent turn is immutable.
When analysis is enabled, attachment responses can include a bounded summary, structured observations, and limitations. These are derived context, not confirmed workflow fields or instructions.
Structured interactions
Supported card kinds are:
collectchoiceconfirm
A submission identifies the card, active phase, kind, action, and submitted values. The server validates that the interaction belongs to the active conversation state so stale or mismatched submissions cannot advance a journey.
Streaming
Runtime delivery can expose progress, typing, response, state, and terminal events. Clients must tolerate reconnects and reconcile against persisted history rather than assuming every transient event was received exactly once.
Errors
Clients should treat authentication, authorization, validation, stale interaction, not-found, conflict, rate-limit, and temporary-service failures as distinct categories. The runtime SDK normalizes these failures for browser consumers.
For exact versioned request and response types, use @nambikk/sdk and the
deployed OpenAPI document.