We are extending our Terraform CX as Code pipeline to manage recording policies programmatically. The standard provider handles static configurations, but we have a requirement to trigger recording states dynamically based on custom queue events. The plan is to use a custom Terraform resource with external providers to hit the recording API directly.
I have written a shell script that the external provider calls to POST to /api/v2/recordings/recording. The goal is to start a recording for a specific conversation.
Here is the curl command being executed:
curl -X POST "https://{{org_host}}.mygenesys.com/api/v2/recordings/recording" \
-H "Authorization: Bearer {{access_token}}" \
-H "Content-Type: application/json" \
-d '{
"conversationId": "8593c4a2-1b2e-4f9a-8d7c-3e2f1a0b9c8d",
"recordingType": "CONVERSATION"
}'
The response comes back as 201 Created, which seems correct. However, the recording does not appear in the UI or the analytics dashboard. When I query the recording status using GET /api/v2/recordings/recording/{recordingId} (using the ID from the response), it returns 404 Not Found.
The JSON payload returned on creation looks like this:
{
"id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"conversationId": "8593c4a2-1b2e-4f9a-8d7c-3e2f1a0b9c8d",
"recordingType": "CONVERSATION",
"status": "STARTED"
}
I am wondering if there is a specific permission scope missing from the OAuth token used in the script. The current scopes are admin:recording and read:recording. The documentation is vague about whether additional scopes are required to actually persist the recording file.
Also, stopping the recording requires a PUT request to the same endpoint with status: STOPPED. I have not tested that yet because the start is failing to persist.
Is this the correct approach for dynamic recording control via API in an automated pipeline?