Last updated: July 23, 2026
Migration map
New integrations should use POST /v1/agents/run for execution, POST /v1/agents/create for definitions, and POST /v1/models/completions for direct model calls—keeping auth headers stable.
Legacy /assistant_* routes remain mounted for backward compatibility, but they do not represent the preferred contract for new enterprise workloads. The /v1 surface inherits current RBAC, governed requests, and routing.
Run agents
Prefer POST /v1/agents/run over legacy assistant chat for new execution flows.
Create agents
Use POST /v1/agents/create for the control-plane definition flow.
Call models
Use POST /v1/models/completions when you need completion rather than an agent run.
Compatibility-first sequence
Inventory legacy calls, migrate execution to /v1/agents/run, validate streaming and tools in staging, then retire assistant routes only when client and server behavior match.
Step through each client: list, update, delete, and chat flows. Keep existing X-Kimss-Key or bearer authentication. Use the SDK conversation_id for continuation even when historical concepts referenced thread_id.
Verify usage attribution and error handling in a non-production workspace before cutover. Not every legacy management endpoint has a one-for-one public SDK wrapper—consult /docs/api_docs.
SDK and MCP alignment
The kimss Python package and optional MCP server track the supported /v1 subset; treat shipped SDK docs as authoritative when mapping old assistant helpers to new resources.
Install with pip install kimss, configure KIMSS_API_KEY, and exercise agent run/create from /python-sdk-mcp-quickstart. MCP tools mirror a focused subset for IDE workflows.
Rollout communication
Tell internal consumers the deprecation timeline, which environments still accept assistant_* calls, and where to report parity gaps before you disable legacy paths.
Track progress in your changelog and link teams to /enterprise-ai-control-plane for architectural context. Published Kimss updates appear at /changelog.