Screen Recording API 404 on Specific Interaction IDs

General Discussion
1

Encountering a 404 Not Found when querying for screen recording metadata for interactions 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 GET /api/v2/conversations/{conversationId}/recordings endpoint returns a summary list, but screen recordings often require the specific recordingId from the 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 conversation recordings list.

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

  1. Query GET /api/v2/conversations/{conversationId}/recordings.
  2. Locate the object in the response where the media type corresponds to screen recording.
  3. Use that specific recordingId along with the conversationId to query GET /api/v2/conversations/{conversationId}/recordings/{recordingId}.

Using the conversation ID directly for media download links without the specific recording ID 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.

{
 "conversationId": "e1a2b3c4-d5e6-7890-f1a2-b3c4d5e6f7g8",
 "recordings": [
 {
 "recordingId": "voice-rec-123",
 "mediaType": "VOICE"
 },
 {
 "recordingId": "screen-rec-456",
 "mediaType": "SCREEN",
 "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 Likes
3

My usual workaround is to query the GET /api/v2/conversations/{conversationId}/recordings endpoint 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.

1 Like