Skip to main content
A conversation client may need to submit text, contextual values, or a client-tool result. The integration must define which data the client can influence and which decisions remain owned by the server.

​
Prepare contextual values

Use dynamic variables to identify named values and expected types. Keep identity, workspace access, resource authorization, and spending policy server-owned. A value submitted by a browser is not proof of any of those permissions. The public initiation schemas describe conversation configuration overrides and contextual data. Their presence does not establish a working session or a released real-time event envelope.

​
Design the request boundary

  1. List the fields a client is allowed to submit and their type and length constraints.
  2. Resolve the authenticated user and workspace independently of submitted identifiers.
  3. Validate tool results against the outstanding request and the owning service’s policy.
  4. Define duplicate, expired, interrupted, and disconnected-request handling.
  5. Verify a complete client request and saved result when the runtime is released.
Use authentication and environment values for the supported preparation workflows. Do not embed a workspace API key in the client.

​
Frequently asked questions

No. Use the exact released override policy and preserve server-owned authorization. Schema fields do not imply unrestricted client control.
No supported Threetone transport contract is established here. Keep runnable transport examples tied to a verified release.