Screen recording metadata not linking to eval forms

General Discussion
1

400 Bad Request on POST /api/v2/recordings/screensessions/metadata. The metadata isn’t hitting the recording, which kills the calibration process since the screen session is missing from the quality evaluation form.

Tried a few things from an old community post about session IDs, but the payload still rejects. The recording policy is active, but the link between the session and the QM eval is broken.

1 Like
2

the 400 on /api/v2/recordings/screensessions/metadata is usually because the payload is missing the exact screenSessionId or the conversationId doesn’t actually match the session. it’s just lovely how the API gives a generic bad request instead of actually telling you which field is wrong. just classic.

you’ll need to make sure the body looks exactly like this, or it’ll just keep rejecting:

{
 "conversationId": "your-conv-id-here",
 "screenSessionId": "your-session-id-here",
 "metadata": {
 "key1": "value1",
 "key2": "value2"
 }
}

TL;DR: double-check that your screenSessionId is current and the conversationId is a perfect match.

hope this helps someone

3 Likes
3 
{
 "conversationId": "string",
 "screenSessionId": "string",
 "metadata": {
 "key": "value"
 }
}

Is the payload using this exact structure? We’ve seen similar issues in other community posts where the metadata format causes a reject. If the precision of the session ID is wrong, the calibration for the eval form won’t work. Can you check if the conversationId is truly active?

4

Cause: The 400 Bad Request on POST /api/v2/recordings/screensessions/metadata usually stems from a race condition. If the Lambda tries to push metadata before the screen recording session is fully indexed or committed in the backend, the API rejects the payload because the screenSessionId isn’t VALID yet. It’s a common timing issue when triggering off conversation events.

Solution: Implement a retry mechanism with exponential backoff. Don’t just fire the request once. Wrap the call in a loop that catches the 400 and waits before trying again.

const axios = require('axios');

async function updateMetadata(sessionId, metadata, retries = 3) {
 for (let i = 0; i < retries; i++) {
 try {
 await axios.post('https://api.mypurecloud.com/api/v2/recordings/screensessions/metadata', {
 screenSessionId: sessionId,
 metadata: metadata
 });
 return; 
 } catch (err) {
 if (err.response?.status === 400 && i < retries - 1) {
 const delay = Math.pow(2, i) * 1000;
 await new Promise(res => setTimeout(res, delay));
 } else {
 throw err;
 }
 }
 }
}

Disclaimer: Be careful with rate limits. If you’re processing thousands of events via EventBridge, aggressive retries can trigger 429s. Always use a Dead Letter Queue (DLQ) for failed events to avoid losing data. Also, ensure the IAM role for the Lambda follows the principle of least privilege.