Can anyone clarify the correct sequence for importing bot configurations via the Genesys Cloud API when a knowledge base is already present in the target environment? We are running an automated deployment pipeline using GitHub Actions. The workflow attempts to push a new bot version to the Production org. The script first creates or updates the knowledge base using PUT /api/v2/bots/knowledgebases/{id}. This step succeeds. Immediately after, the script calls POST /api/v2/bots/{botId}/versions to publish the new version. The request payload includes the updated knowledge base ID. The API returns a 409 Conflict error. The response body indicates that the knowledge base link is invalid or already associated with another bot version. We suspect the issue relates to the asynchronous nature of knowledge base indexing or a race condition in the API state. The environment uses Genesys Cloud provider v2.10.0 in Terraform for initial scaffolding, but the bot versioning is handled via direct REST calls in a Node.js wrapper script. The error occurs consistently on the second run of the pipeline. The first run succeeds. Subsequent runs fail on the knowledge base association step. We have added a 30-second delay between the knowledge base update and the bot version publish. This does not resolve the issue. The error message remains identical. We need to understand if there is a specific API endpoint to verify knowledge base readiness before linking, or if the payload structure for bot versioning requires a different approach to handle existing resources. Current payload structure attaches the knowledge base ID directly in the bot config object during the version creation request.
We are observing this behavior in the Australia/Sydney region endpoint. The bot utilizes standard NLP capabilities with a custom knowledge base. No custom skills or integrations are involved in this specific failure. The Terraform state file shows the knowledge base resource as unchanged. The API logs from the developer console show a successful 200 OK for the knowledge base PUT request. However, the subsequent bot version POST fails immediately with 409. We have checked the bot’s current active version. It does not have a locked status. The issue appears isolated to the linkage between the bot version and the knowledge base resource during the publish phase. We require a reliable method to ensure the knowledge base is fully indexed and available for linking before the bot versioning step executes. Any insights on the correct API sequence or necessary headers to force a refresh of the resource state would be appreciated. We are currently blocked on deploying updated bot logic to production due to this conflict.