Screen Recording API dropping playbackUrl in sa-east-1 webhook payload

General Discussion
1

Problem

The Screen Recording API keeps dropping the playbackUrl field when polling for completed sessions. The webhook catches the screen.recording.completed event, but it doesn’t populate the URL. The downstream NRQL ingestion pipeline expects that link to trigger a custom event. The payload arrives, but it’s missing the actual reference. This broke latency tracking for the Sao Paulo queue last Tuesday. Console shows the file exists in storage. Logs are doing jack all right now.

Code

import requests
headers = {"Authorization": f"Bearer {TOKEN}", "Content-Type": "application/json"}
resp = requests.get(
 "https://api.mypurecloud.com/api/v2/screenrecordings/{id}",
 headers=headers
)

Error

{
 "code": "bad.request",
 "message": "Unable to process recording metadata. Playback link generation failed for tenant region sa-east-1.",
 "status": 422
}

Question

Is the playbackUrl intentionally deferred until a separate async job finishes, or does the v2 endpoint require a specific header to force synchronous generation? The docs mention S3 bucket permissions, but IAM roles aren’t the issue. Just need to know if this is a known SDK mapping issue or a region-specific throttle. The timeout window keeps hitting 30 seconds.

2

PureCloudPlatformClientV2 returns the full object when you query the endpoint directly, but the webhook payload truncates it by default. We tried adding screen:recordings:view to the OAuth scopes. That failed to populate the webhook. We also tested the subscription template editor. It doesn’t expose the playbackUrl field. Direct API pull works fine. The URL shows up there. You’ll need a manual fetch. Here is the curl command we use after the event fires:

curl -X GET "https://api.mypurecloud.com/api/v2/screenrecordings/{recordingId}" \
 -H "Authorization: Bearer $TOKEN" \
 -H "Accept: application/json"

The response body contains the playbackUrl field under the playback object. Does your downstream pipeline support a secondary REST call, or are you forcing everything into the initial webhook body? The latency usually spikes when we batch these requests.