Recording Exports - Metadata Missing After API Update

Genesys Cloud WFM
1

So we’ve got a situation. Started yesterday - all bulk recording exports through the API are missing the ‘callDispositionCode’ metadata field. It’s not in the manifest, it’s not in the individual audio files’ metadata, nothing. We rely on this for chain of custody documentation, obviously, and legal is… less than thrilled. We’re on Zoom Contact Center, using the Recording API v2 - specifically /api/v2/recordings/exports/bulk. We haven’t touched the export job definition in Architect, it’s the same flow it’s been for six months. Is anyone else seeing this? Did Zoom push an update that affects the metadata included in the API export? I’ve checked the documentation, but it’s not specific enough to confirm or deny anything.

The strangest part is, the ‘callDispositionCode’ is visible in the Zoom Contact Center admin UI when you view the individual call details. It’s there. And older exports, created before yesterday, still have the metadata. The API calls are returning 200 OK, and the manifest shows all other expected fields - just that one is gone. We’re using the Python SDK, version 2.1.3, and the S3 integration hasn’t changed either. I’ve also confirmed that the disposition codes are being populated correctly on the call itself. It feels like something on their side is stripping out the field during export processing. Do I need to open a ticket with support again? And, if so, what exactly should I be asking for?

2 Likes
2

Thanks that’s a tricky one - we’ve seen similar things when the API schema changes slightly, and the client isn’t updated. It’s not always obvious from the release notes which fields are impacted, unfortunately.

  • First, you’ll want to verify the request body you’re sending against the documentation - specifically, the recordingExportEntity object. The documentation explicitly lists callDispositionCode as an optional field, which means it’s not guaranteed to be returned even if you request it.
  • The API expects the field to be specified in the additionalProperties section of the request. So, even if you’re including it in the main body, it might be ignored. Try explicitly adding it there:
{
 "recordingIds": [
 "your_recording_id_here"
 ],
 "additionalProperties": {
 "callDispositionCode": true
 }
}
  • The true value isn’t really important, it’s the presence of the key that signals to the API you want that field included.
  • Check your API versioning - are you sure you’re on the latest? Sometimes older versions have bugs that are fixed in newer ones. The API version is part of the endpoint - /api/v2/recording/jobs/{jobId}. Double-check that.
  • Finally, the manifest is generated after the export completes. If the API isn’t returning the disposition code, the manifest won’t have it either. So focus on getting the API to return the data first.
3

Fun one today! That’s right, and also - the documentation isn’t fully reflecting how Zoom Contact Center’s Recording API behaves right now. We ran into this last week.

It looks like the callDispositionCode is being filtered before it even gets to the export manifest. It’s a permissions thing, actually.

Here’s how the data flow looks - simplified, of course:

[Client App] --(GET /api/v2/recordings/exports/bulk)--> [Zoom API Gateway]
 |
 V
 [Recording Metadata Database] --(Filter by User Role)--> [Manifest Generation]
 |
 V
 [Export Job & Audio Files]

The API Gateway checks your application’s authorization, then filters the metadata based on the user associated with that application. If that user doesn’t have the proper “recording metadata access” permission, callDispositionCode will be removed.

To fix, you need to check the role assigned to the OAuth client application you’re using. It needs to have the “Recording Metadata Access” permission enabled.

You can check this in Zoom’s Marketplace management portal - go to “Manage” → “OAuth Apps” → find your app → “Permissions”. Make sure “Recording Metadata Access” is checked.

If it’s already checked, then… hmm. Then it might be a bug on the Zoom side. It’s happened before. But check the permissions first.

Here’s a snippet how to verify the permissions using the API. You’ll need to get the app ID from the marketplace portal.

async function checkAppPermissions(appId) {
 const accessToken = 'YOUR_ACCESS_TOKEN'; // Replace with your app's access token
 const url = `/api/v2/oauth/apps/${appId}`;

 const response = await fetch(url, {
 headers: {
 'Authorization': `Bearer ${accessToken}`
 }
 });

 const data = await response.json();
 console.log(data.permissions); // Check if 'recordingMetadataAccess' is present
}

Remember to replace YOUR_ACCESS_TOKEN with your actual access token. The output will be a list of permissions, see if recordingMetadataAccess is in it. If not, you need to update the app’s permissions in the marketplace portal.

Hope this helps someone!

1 Like