Can anyone explain why the POST request to /api/v2/analytics/conversations/ai/botstudio/bots/{botId}/intents consistently returns a 409 Conflict error when executed through our multi-org integration service?
We are deploying a standardized AI bot template across several client organizations using a service account with full admin:bot:read and admin:bot:write scopes. The intent definition payload matches the schema requirements found in the Bot Studio API Reference.
The issue appears specifically when updating an existing intent that has already been published to a live bot version. The response body indicates a version mismatch, suggesting the API expects an If-Match header with the current ETag, yet the documentation does not explicitly mandate optimistic locking for intent updates in this context.
Our implementation fetches the current bot configuration, modifies the intent payload, and attempts a direct update. This works in development environments but fails in production staging. Is there a requirement to retrieve the latest ETag immediately prior to the update call, or is there a specific workflow for handling concurrent modifications in a multi-tenant deployment scenario?