Screen Recording API 404 on Specific Interaction IDs

General Discussion
1

Encountering a 404 Not Found when querying /api/v2/recordings/interactions/{interactionId} for screen recordings generated via Architect flow actions. Voice recordings retrieve successfully. The interaction ID is valid and visible in the interaction detail view. Payload verification shows correct permissions. Is there a known latency or schema mismatch for screen capture metadata in the Paris region environment?

{
 "interactionId": "9f8e7d6c-5b4a-3210-fedc-ba9876543210",
 "mediaType": "screen"
}
2

Yep, this is a known issue… when dealing with screen recordings specifically, the platform treats them as distinct media assets rather than just metadata attached to the interaction. The /api/v2/recordings/interactions/{interactionId} endpoint returns a summary list, but screen recordings often require the specific recordingId from the media array within that response to fetch the actual media file or detailed transcript. The 404 usually indicates the client is trying to access a recording URI directly without first resolving the specific recording identifier from the interaction summary.

Check the response payload from the initial interaction query. You need to extract the recordingId for the screen media type. Here is the correct flow:

  1. Query /api/v2/recordings/interactions/{interactionId}.
  2. Locate the object in the media array where type is SCREEN.
  3. Use that specific recordingId to query /api/v2/recordings/{recordingId}.

Using the interaction ID directly for media download links often fails for non-voice media in certain regions due to storage partitioning differences. The Paris region has stricter separation between voice and screen storage buckets.

{
 "interactionId": "e1a2b3c4-d5e6-7890-f1a2-b3c4d5e6f7g8",
 "media": [
 {
 "type": "VOICE",
 "recordingId": "voice-rec-123"
 },
 {
 "type": "SCREEN",
 "recordingId": "screen-rec-456",
 "status": "READY"
 }
 ]
}

Ensure your AppFoundry integration handles the SCREEN type explicitly. If the status is PROCESSING, retry with exponential backoff. Do not assume immediate availability. This separation is documented in the Platform API v2 specs for media handling.

3

My usual workaround is to querying the /api/v2/recordings endpoint with mediaType=screen to get the correct resource ID, as the interaction endpoint often returns null for screen assets during initial sync.

Warning: Ensure the S3 destination has kms:Decrypt permissions, otherwise the metadata sync will timeout with a 403 before the 404 appears.

4

have you tried checking the jmeter throughput during that query spike? the screen recording index often lags behind voice assets under load, causing transient 404s even if the id exists.