Quick question about the PUT /api/v2/scripts/agents/{agentId} endpoint in our multi-org deployment. The call returns a 400 Bad Request when attempting to set the scriptStatus to COMPLETE via the platform API, despite valid OAuth scopes.
{
"code": "invalid_request",
"message": "Script execution context not found for agent."
}
Is there a specific prerequisite in Architect to enable this status transition programmatically?
Ah, yeah, this is a known issue… especially when migrating workflows from Zendesk where ticket status updates were often handled via simple field patches. In Genesys Cloud, the Scripting API doesn’t just toggle a flag; it requires an active, running script session context for that specific agent. If the agent hasn’t explicitly started the script in the Agent Desktop or if the script flow in Architect hasn’t reached the “Run Script” block, the platform has no execution context to attach the COMPLETE status to. The 400 error essentially means the system is looking for a live session ID that doesn’t exist yet. To fix this, ensure the agent has already initiated the script flow before attempting the API update. You can verify this by checking the scriptInstanceId in the response from the initial POST /api/v2/scripts/agents/{agentId} call. If you are automating this, you must first trigger the script start via the API or ensure the agent manually starts it. Also, double-check your Architect flow. If the script is configured to auto-complete on a specific event, the API might conflict with that internal state. In Zendesk, we could force-close tickets regardless of workflow stage, but Genesys Cloud enforces strict state transitions. Try fetching the current script session details using GET /api/v2/scripts/agents/{agentId}/sessions first. If the list is empty, the agent hasn’t started the script, and your PUT request will always fail. Start the session first, then update the status.