Workflow and legacy agent application API

​

Impact of publishing a new version on API calls

After an application publishes a new version, APP_ID always points to the latest published version. Requests that are already in progress when the new version is published are not interrupted; they complete normally under the version that was active when they started. New requests sent through the same APP_ID after publishing use the new version's configuration, including the prompt, model, and tools. The API does not support calling a historical version through a request parameter. The request body contains only the input and parameters fields, and provides no version number or historical-version parameter. If you keep using a multi-round conversation session_id after a new version is published, the model may misinterpret the conversation context, or tool calling may behave unexpectedly, because the session's history was produced under the previous version's configuration. End active multi-round conversations before you publish a major change, or start a new conversation with a new session_id after publishing. To restore a previous configuration, roll back the version on the application details page in the Model Studio console:

1. Click Version management.
2. Select the historical version that you want to restore.
3. Click Overwrite current draft.
4. Click Publish to apply the rollback.

To reduce the impact on online calls, publish major changes during off-peak hours. If you need to serve multiple versions at the same time, create multiple applications with different APP_ID values to manage versions.