Genesys Cloud - Developer Community!

Hi Team,

We are exploring ways to optimize the retrieval of daily CDR data and associated recording metadata for over 200,000 conversations using Genesys Cloud APIs, while staying within the API rate limits and improving performance.

1. Export Request:
   We initiate the export using:
   POST /api/v2/analytics/reporting/exports
   with the required parameters for <Interaction Search View> to submit the request to Genesys.
2. Export Status Check:
   After ~30 minutes, we check the status using:
   GET /api/v2/analytics/reporting/exports/<export_id>
   If the status is COMPLETED, we proceed to download the data.
3. Paginated CSV Retrieval:
   Given the volume and the Genesys rate limit of 2,500 rows per CSV, we anticipate needing to call:
   GET /api/v2/analytics/reporting/exports/<export_id>?pageNumber=1
   through to possibly pageNumber=100 or more to retrieve all data per day.
4. Recording Metadata Retrieval:
   For each conversation, we also need to retrieve recording metadata using:
   GET /api/v2/conversations/{conversationId}/recordingmetadata
   This could result in 200,000+ API calls per day.

• Is this approach acceptable within the current rate limits?
• Would you recommend any optimizations or batching strategies to handle this scale more efficiently?
• Is there a bulk API for recording metadata that could reduce the number of individual calls?

Hi Team,

We are exploring ways to optimize the retrieval of daily CDR data and associated recording metadata for over 200,000 conversations using Genesys Cloud APIs, while staying within the API rate limits and improving performance.

1. Export Request:
   We initiate the export using:
   POST /api/v2/analytics/reporting/exports
   with the required parameters for <Interaction Search View> to submit the request to Genesys.
2. Export Status Check:
   After ~30 minutes, we check the status using:
   GET /api/v2/analytics/reporting/exports/<export_id>
   If the status is COMPLETED, we proceed to download the data.
3. Paginated CSV Retrieval:
   Given the volume and the Genesys rate limit of 2,500 rows per CSV, we anticipate needing to call:
   GET /api/v2/analytics/reporting/exports/<export_id>?pageNumber=1
   through to possibly pageNumber=100 or more to retrieve all data per day.
4. Recording Metadata Retrieval:
   For each conversation, we also need to retrieve recording metadata using:
   GET /api/v2/conversations/{conversationId}/recordingmetadata
   This could result in 200,000+ API calls per day.

• Is this approach acceptable within the current rate limits?
• Would you recommend any optimizations or batching strategies to handle this scale more efficiently?
• Is there a bulk API for recording metadata that could reduce the number of individual calls?

Hi Team,

We are exploring ways to optimize the retrieval of daily CDR data and associated recording metadata for over 200,000 conversations using Genesys Cloud APIs, while staying within the API rate limits and improving performance.

1. Export Request:
   We initiate the export using:
   POST /api/v2/analytics/reporting/exports
   with the required parameters for <Interaction Search View> to submit the request to Genesys.
2. Export Status Check:
   After ~30 minutes, we check the status using:
   GET /api/v2/analytics/reporting/exports/<export_id>
   If the status is COMPLETED, we proceed to download the data.
3. Paginated CSV Retrieval:
   Given the volume and the Genesys rate limit of 2,500 rows per CSV, we anticipate needing to call:
   GET /api/v2/analytics/reporting/exports/<export_id>?pageNumber=1
   through to possibly pageNumber=100 or more to retrieve all data per day.
4. Recording Metadata Retrieval:
   For each conversation, we also need to retrieve recording metadata using:
   GET /api/v2/conversations/{conversationId}/recordingmetadata
   This could result in 200,000+ API calls per day.

• Is this approach acceptable within the current rate limits?
• Would you recommend any optimizations or batching strategies to handle this scale more efficiently?
• Is there a bulk API for recording metadata that could reduce the number of individual calls?

Hi Vikas,

In general we don't recommend calling the individual API iteratively for sweeping through all recordings in the system.

I can think of a couple of things:

• There is the recording bulk action API that will export recordings -- including both the recording asset and the metadata -- to an S3 bucket. See https://help.mypurecloud.com/articles/working-with-exported-recordings-in-aws-s3-bucket/ for details.  There's also a Glue+Athena reference example to search from the S3.
• If you don't need recording-specific metadata (e.g. recording start/end time, duration) -- since most metadata are found at the conversation level as you have the Analytics export -- you don't need that last step of recording metadata retrieval at all.  If you just need some confirmation that these recordings are captured, you can instead go looking for Recording Create audit event at the async Audit Event API.

Hi Team,

We are exploring ways to optimize the retrieval of daily CDR data and associated recording metadata for over 200,000 conversations using Genesys Cloud APIs, while staying within the API rate limits and improving performance.

1. Export Request:
   We initiate the export using:
   POST /api/v2/analytics/reporting/exports
   with the required parameters for <Interaction Search View> to submit the request to Genesys.
2. Export Status Check:
   After ~30 minutes, we check the status using:
   GET /api/v2/analytics/reporting/exports/<export_id>
   If the status is COMPLETED, we proceed to download the data.
3. Paginated CSV Retrieval:
   Given the volume and the Genesys rate limit of 2,500 rows per CSV, we anticipate needing to call:
   GET /api/v2/analytics/reporting/exports/<export_id>?pageNumber=1
   through to possibly pageNumber=100 or more to retrieve all data per day.
4. Recording Metadata Retrieval:
   For each conversation, we also need to retrieve recording metadata using:
   GET /api/v2/conversations/{conversationId}/recordingmetadata
   This could result in 200,000+ API calls per day.

• Is this approach acceptable within the current rate limits?
• Would you recommend any optimizations or batching strategies to handle this scale more efficiently?
• Is there a bulk API for recording metadata that could reduce the number of individual calls?

Hi @Daniel Ho,

Thanks for your suggestions. I'm aware of the Genesys AWS S3 export and we are currently using it. However, the metadata file generated through this export doesn't include all the details we need. For example:

• UserID is provided, but the username string is not included.

• QueueID is available, but not the queue name string.

• There's no information about the Division related to the call.

Because of these limitations, we considered using the Conversation Exports via the Analytics API and then attaching the recording metadata using the earlier mentioned API. Yes, I understand this results in a large number of API calls for a complete daily call data report.

Could you please suggest any alternative approach that avoids these excessive API calls? We do not require the media files, only the metadata.

sample metadata:
{
  "conversation_id": "5d6f338a-39c8-443c-a2b7-e3d2ef758567",
  "users": "garima balodi; vikas shetty",
  "date": "7/1/25 06:51 AM",
  "duration": "06:05",
  "direction": "Inbound",
  "queue": "InstaCCEngineering",
  "wrap_up": "dummy; Demo",
  "ani": "tel:+918***********",
  "dnis": "tel:+191**********",
  "transferred": "YES",
  "consult_transferred": "YES",
  "recording": "YES",
  "division": "Home",
  "disconnect_type": "External",
  "screen_recorded": "NO",
  "recordings": [
    {
      "recording_id": "9e6f7806-aeee-48ba-8088-be79ac14f9b5",
      "conversation_id": "5d6f338a-39c8-443c-a2b7-e3d2ef758567",
      "start_time": "2025-07-01T06:51:38.974Z",
      "end_time": "2025-07-01T06:57:20.354Z",
      "media": "audio",
      "media_subtype": "Trunk",
      "region": "us-east-1"
    },
    {
      "recording_id": "8030babc-6742-4757-9e57-3c421e00813b",
      "conversation_id": "5d6f338a-39c8-443c-a2b7-e3d2ef758567",
      "start_time": "2025-07-01T06:56:16.687Z",
      "end_time": "2025-07-01T06:56:43.607Z",
      "media": "audio",
      "media_subtype": "Consult",
      "region": "us-east-1"
    }
  ]
}

Thanks in advance for your guidance.

Hi Vikas,

In general we don't recommend calling the individual API iteratively for sweeping through all recordings in the system.

I can think of a couple of things:

• There is the recording bulk action API that will export recordings -- including both the recording asset and the metadata -- to an S3 bucket. See https://help.mypurecloud.com/articles/working-with-exported-recordings-in-aws-s3-bucket/ for details.  There's also a Glue+Athena reference example to search from the S3.
• If you don't need recording-specific metadata (e.g. recording start/end time, duration) -- since most metadata are found at the conversation level as you have the Analytics export -- you don't need that last step of recording metadata retrieval at all.  If you just need some confirmation that these recordings are captured, you can instead go looking for Recording Create audit event at the async Audit Event API.

Hi Team,

We are exploring ways to optimize the retrieval of daily CDR data and associated recording metadata for over 200,000 conversations using Genesys Cloud APIs, while staying within the API rate limits and improving performance.

1. Export Request:
   We initiate the export using:
   POST /api/v2/analytics/reporting/exports
   with the required parameters for <Interaction Search View> to submit the request to Genesys.
2. Export Status Check:
   After ~30 minutes, we check the status using:
   GET /api/v2/analytics/reporting/exports/<export_id>
   If the status is COMPLETED, we proceed to download the data.
3. Paginated CSV Retrieval:
   Given the volume and the Genesys rate limit of 2,500 rows per CSV, we anticipate needing to call:
   GET /api/v2/analytics/reporting/exports/<export_id>?pageNumber=1
   through to possibly pageNumber=100 or more to retrieve all data per day.
4. Recording Metadata Retrieval:
   For each conversation, we also need to retrieve recording metadata using:
   GET /api/v2/conversations/{conversationId}/recordingmetadata
   This could result in 200,000+ API calls per day.

• Is this approach acceptable within the current rate limits?
• Would you recommend any optimizations or batching strategies to handle this scale more efficiently?
• Is there a bulk API for recording metadata that could reduce the number of individual calls?

Hi @Vikas Shetty, I have a similar requirement and have done it slightly differently.
I have scheduled a daily export based on an interactions tab that captures all the possible information, baring the participant attributes. It is good for our purpose, but may not be suitable to your requirements.

In addition I have an API based solution that we run ad-hoc if required, especially to download bulk recordings. This process uses a combination of following Java SDK API;
postAnalyticsConcersationDetailsJobs
getAnalyticsConversationDetailsJob
getAnalyticsConcersationsDetailsJobResults
getRecordingBatchrequest
postRecordingBatchrequests
getConversationRecordingmetadata

With this I am able to download a months worth of recordings/data at a time and I believe you can use the above API's in combination to get to your specific requirements for 1 day. To avoid rate limit issues, I run the download process in batches of 10. As you are not going to download anything just reporting data, I am sure this would be much faster.
Hope this helps.

Hi @Daniel Ho,

Thanks for your suggestions. I'm aware of the Genesys AWS S3 export and we are currently using it. However, the metadata file generated through this export doesn't include all the details we need. For example:

• UserID is provided, but the username string is not included.

• QueueID is available, but not the queue name string.

• There's no information about the Division related to the call.

Because of these limitations, we considered using the Conversation Exports via the Analytics API and then attaching the recording metadata using the earlier mentioned API. Yes, I understand this results in a large number of API calls for a complete daily call data report.

Could you please suggest any alternative approach that avoids these excessive API calls? We do not require the media files, only the metadata.

sample metadata:
{
  "conversation_id": "5d6f338a-39c8-443c-a2b7-e3d2ef758567",
  "users": "garima balodi; vikas shetty",
  "date": "7/1/25 06:51 AM",
  "duration": "06:05",
  "direction": "Inbound",
  "queue": "InstaCCEngineering",
  "wrap_up": "dummy; Demo",
  "ani": "tel:+918***********",
  "dnis": "tel:+191**********",
  "transferred": "YES",
  "consult_transferred": "YES",
  "recording": "YES",
  "division": "Home",
  "disconnect_type": "External",
  "screen_recorded": "NO",
  "recordings": [
    {
      "recording_id": "9e6f7806-aeee-48ba-8088-be79ac14f9b5",
      "conversation_id": "5d6f338a-39c8-443c-a2b7-e3d2ef758567",
      "start_time": "2025-07-01T06:51:38.974Z",
      "end_time": "2025-07-01T06:57:20.354Z",
      "media": "audio",
      "media_subtype": "Trunk",
      "region": "us-east-1"
    },
    {
      "recording_id": "8030babc-6742-4757-9e57-3c421e00813b",
      "conversation_id": "5d6f338a-39c8-443c-a2b7-e3d2ef758567",
      "start_time": "2025-07-01T06:56:16.687Z",
      "end_time": "2025-07-01T06:56:43.607Z",
      "media": "audio",
      "media_subtype": "Consult",
      "region": "us-east-1"
    }
  ]
}

Thanks in advance for your guidance.

Hi Vikas,

In general we don't recommend calling the individual API iteratively for sweeping through all recordings in the system.

I can think of a couple of things:

• There is the recording bulk action API that will export recordings -- including both the recording asset and the metadata -- to an S3 bucket. See https://help.mypurecloud.com/articles/working-with-exported-recordings-in-aws-s3-bucket/ for details.  There's also a Glue+Athena reference example to search from the S3.
• If you don't need recording-specific metadata (e.g. recording start/end time, duration) -- since most metadata are found at the conversation level as you have the Analytics export -- you don't need that last step of recording metadata retrieval at all.  If you just need some confirmation that these recordings are captured, you can instead go looking for Recording Create audit event at the async Audit Event API.

Hi Team,

We are exploring ways to optimize the retrieval of daily CDR data and associated recording metadata for over 200,000 conversations using Genesys Cloud APIs, while staying within the API rate limits and improving performance.

1. Export Request:
   We initiate the export using:
   POST /api/v2/analytics/reporting/exports
   with the required parameters for <Interaction Search View> to submit the request to Genesys.
2. Export Status Check:
   After ~30 minutes, we check the status using:
   GET /api/v2/analytics/reporting/exports/<export_id>
   If the status is COMPLETED, we proceed to download the data.
3. Paginated CSV Retrieval:
   Given the volume and the Genesys rate limit of 2,500 rows per CSV, we anticipate needing to call:
   GET /api/v2/analytics/reporting/exports/<export_id>?pageNumber=1
   through to possibly pageNumber=100 or more to retrieve all data per day.
4. Recording Metadata Retrieval:
   For each conversation, we also need to retrieve recording metadata using:
   GET /api/v2/conversations/{conversationId}/recordingmetadata
   This could result in 200,000+ API calls per day.

• Is this approach acceptable within the current rate limits?
• Would you recommend any optimizations or batching strategies to handle this scale more efficiently?
• Is there a bulk API for recording metadata that could reduce the number of individual calls?

Hi @Vineet Kakroo,

Thank you for your response. Yes, your understanding is correct-I need just the metadata.

I have evaluated the SDK, and it indeed uses the same APIs. My main challenge is how to efficiently handle a huge volume of records per day on managing large-scale data retrieval using these APIs/SDK?

Thanks again for your help!

Hi @Vikas Shetty, I have a similar requirement and have done it slightly differently.
I have scheduled a daily export based on an interactions tab that captures all the possible information, baring the participant attributes. It is good for our purpose, but may not be suitable to your requirements.

In addition I have an API based solution that we run ad-hoc if required, especially to download bulk recordings. This process uses a combination of following Java SDK API;
postAnalyticsConcersationDetailsJobs
getAnalyticsConversationDetailsJob
getAnalyticsConcersationsDetailsJobResults
getRecordingBatchrequest
postRecordingBatchrequests
getConversationRecordingmetadata

With this I am able to download a months worth of recordings/data at a time and I believe you can use the above API's in combination to get to your specific requirements for 1 day. To avoid rate limit issues, I run the download process in batches of 10. As you are not going to download anything just reporting data, I am sure this would be much faster.
Hope this helps.

Hi @Daniel Ho,

Thanks for your suggestions. I'm aware of the Genesys AWS S3 export and we are currently using it. However, the metadata file generated through this export doesn't include all the details we need. For example:

• UserID is provided, but the username string is not included.

• QueueID is available, but not the queue name string.

• There's no information about the Division related to the call.

Because of these limitations, we considered using the Conversation Exports via the Analytics API and then attaching the recording metadata using the earlier mentioned API. Yes, I understand this results in a large number of API calls for a complete daily call data report.

Could you please suggest any alternative approach that avoids these excessive API calls? We do not require the media files, only the metadata.

sample metadata:
{
  "conversation_id": "5d6f338a-39c8-443c-a2b7-e3d2ef758567",
  "users": "garima balodi; vikas shetty",
  "date": "7/1/25 06:51 AM",
  "duration": "06:05",
  "direction": "Inbound",
  "queue": "InstaCCEngineering",
  "wrap_up": "dummy; Demo",
  "ani": "tel:+918***********",
  "dnis": "tel:+191**********",
  "transferred": "YES",
  "consult_transferred": "YES",
  "recording": "YES",
  "division": "Home",
  "disconnect_type": "External",
  "screen_recorded": "NO",
  "recordings": [
    {
      "recording_id": "9e6f7806-aeee-48ba-8088-be79ac14f9b5",
      "conversation_id": "5d6f338a-39c8-443c-a2b7-e3d2ef758567",
      "start_time": "2025-07-01T06:51:38.974Z",
      "end_time": "2025-07-01T06:57:20.354Z",
      "media": "audio",
      "media_subtype": "Trunk",
      "region": "us-east-1"
    },
    {
      "recording_id": "8030babc-6742-4757-9e57-3c421e00813b",
      "conversation_id": "5d6f338a-39c8-443c-a2b7-e3d2ef758567",
      "start_time": "2025-07-01T06:56:16.687Z",
      "end_time": "2025-07-01T06:56:43.607Z",
      "media": "audio",
      "media_subtype": "Consult",
      "region": "us-east-1"
    }
  ]
}

Thanks in advance for your guidance.

Hi Vikas,

In general we don't recommend calling the individual API iteratively for sweeping through all recordings in the system.

I can think of a couple of things:

• There is the recording bulk action API that will export recordings -- including both the recording asset and the metadata -- to an S3 bucket. See https://help.mypurecloud.com/articles/working-with-exported-recordings-in-aws-s3-bucket/ for details.  There's also a Glue+Athena reference example to search from the S3.
• If you don't need recording-specific metadata (e.g. recording start/end time, duration) -- since most metadata are found at the conversation level as you have the Analytics export -- you don't need that last step of recording metadata retrieval at all.  If you just need some confirmation that these recordings are captured, you can instead go looking for Recording Create audit event at the async Audit Event API.

Hi Team,

We are exploring ways to optimize the retrieval of daily CDR data and associated recording metadata for over 200,000 conversations using Genesys Cloud APIs, while staying within the API rate limits and improving performance.

1. Export Request:
   We initiate the export using:
   POST /api/v2/analytics/reporting/exports
   with the required parameters for <Interaction Search View> to submit the request to Genesys.
2. Export Status Check:
   After ~30 minutes, we check the status using:
   GET /api/v2/analytics/reporting/exports/<export_id>
   If the status is COMPLETED, we proceed to download the data.
3. Paginated CSV Retrieval:
   Given the volume and the Genesys rate limit of 2,500 rows per CSV, we anticipate needing to call:
   GET /api/v2/analytics/reporting/exports/<export_id>?pageNumber=1
   through to possibly pageNumber=100 or more to retrieve all data per day.
4. Recording Metadata Retrieval:
   For each conversation, we also need to retrieve recording metadata using:
   GET /api/v2/conversations/{conversationId}/recordingmetadata
   This could result in 200,000+ API calls per day.

• Is this approach acceptable within the current rate limits?
• Would you recommend any optimizations or batching strategies to handle this scale more efficiently?
• Is there a bulk API for recording metadata that could reduce the number of individual calls?

Check the API's I mentioned, these will get conversations in bulk and that will reduce the amount of API calls that you may be handling currently with the export API's you mentioned at the start. I have not used the export API's but seems they are not efficient in this aspect.

Hi @Vineet Kakroo,

Thank you for your response. Yes, your understanding is correct-I need just the metadata.

I have evaluated the SDK, and it indeed uses the same APIs. My main challenge is how to efficiently handle a huge volume of records per day on managing large-scale data retrieval using these APIs/SDK?

Thanks again for your help!

Hi @Vikas Shetty, I have a similar requirement and have done it slightly differently.
I have scheduled a daily export based on an interactions tab that captures all the possible information, baring the participant attributes. It is good for our purpose, but may not be suitable to your requirements.

In addition I have an API based solution that we run ad-hoc if required, especially to download bulk recordings. This process uses a combination of following Java SDK API;
postAnalyticsConcersationDetailsJobs
getAnalyticsConversationDetailsJob
getAnalyticsConcersationsDetailsJobResults
getRecordingBatchrequest
postRecordingBatchrequests
getConversationRecordingmetadata

With this I am able to download a months worth of recordings/data at a time and I believe you can use the above API's in combination to get to your specific requirements for 1 day. To avoid rate limit issues, I run the download process in batches of 10. As you are not going to download anything just reporting data, I am sure this would be much faster.
Hope this helps.

Hi @Daniel Ho,

Thanks for your suggestions. I'm aware of the Genesys AWS S3 export and we are currently using it. However, the metadata file generated through this export doesn't include all the details we need. For example:

• UserID is provided, but the username string is not included.

• QueueID is available, but not the queue name string.

• There's no information about the Division related to the call.

Because of these limitations, we considered using the Conversation Exports via the Analytics API and then attaching the recording metadata using the earlier mentioned API. Yes, I understand this results in a large number of API calls for a complete daily call data report.

Could you please suggest any alternative approach that avoids these excessive API calls? We do not require the media files, only the metadata.

sample metadata:
{
  "conversation_id": "5d6f338a-39c8-443c-a2b7-e3d2ef758567",
  "users": "garima balodi; vikas shetty",
  "date": "7/1/25 06:51 AM",
  "duration": "06:05",
  "direction": "Inbound",
  "queue": "InstaCCEngineering",
  "wrap_up": "dummy; Demo",
  "ani": "tel:+918***********",
  "dnis": "tel:+191**********",
  "transferred": "YES",
  "consult_transferred": "YES",
  "recording": "YES",
  "division": "Home",
  "disconnect_type": "External",
  "screen_recorded": "NO",
  "recordings": [
    {
      "recording_id": "9e6f7806-aeee-48ba-8088-be79ac14f9b5",
      "conversation_id": "5d6f338a-39c8-443c-a2b7-e3d2ef758567",
      "start_time": "2025-07-01T06:51:38.974Z",
      "end_time": "2025-07-01T06:57:20.354Z",
      "media": "audio",
      "media_subtype": "Trunk",
      "region": "us-east-1"
    },
    {
      "recording_id": "8030babc-6742-4757-9e57-3c421e00813b",
      "conversation_id": "5d6f338a-39c8-443c-a2b7-e3d2ef758567",
      "start_time": "2025-07-01T06:56:16.687Z",
      "end_time": "2025-07-01T06:56:43.607Z",
      "media": "audio",
      "media_subtype": "Consult",
      "region": "us-east-1"
    }
  ]
}

Thanks in advance for your guidance.

Hi Vikas,

In general we don't recommend calling the individual API iteratively for sweeping through all recordings in the system.

I can think of a couple of things:

• There is the recording bulk action API that will export recordings -- including both the recording asset and the metadata -- to an S3 bucket. See https://help.mypurecloud.com/articles/working-with-exported-recordings-in-aws-s3-bucket/ for details.  There's also a Glue+Athena reference example to search from the S3.
• If you don't need recording-specific metadata (e.g. recording start/end time, duration) -- since most metadata are found at the conversation level as you have the Analytics export -- you don't need that last step of recording metadata retrieval at all.  If you just need some confirmation that these recordings are captured, you can instead go looking for Recording Create audit event at the async Audit Event API.

Hi Team,

We are exploring ways to optimize the retrieval of daily CDR data and associated recording metadata for over 200,000 conversations using Genesys Cloud APIs, while staying within the API rate limits and improving performance.

1. Export Request:
   We initiate the export using:
   POST /api/v2/analytics/reporting/exports
   with the required parameters for <Interaction Search View> to submit the request to Genesys.
2. Export Status Check:
   After ~30 minutes, we check the status using:
   GET /api/v2/analytics/reporting/exports/<export_id>
   If the status is COMPLETED, we proceed to download the data.
3. Paginated CSV Retrieval:
   Given the volume and the Genesys rate limit of 2,500 rows per CSV, we anticipate needing to call:
   GET /api/v2/analytics/reporting/exports/<export_id>?pageNumber=1
   through to possibly pageNumber=100 or more to retrieve all data per day.
4. Recording Metadata Retrieval:
   For each conversation, we also need to retrieve recording metadata using:
   GET /api/v2/conversations/{conversationId}/recordingmetadata
   This could result in 200,000+ API calls per day.

• Is this approach acceptable within the current rate limits?
• Would you recommend any optimizations or batching strategies to handle this scale more efficiently?
• Is there a bulk API for recording metadata that could reduce the number of individual calls?

Hi @Vineet Kakroo,

Thanks for taking the time to share your approach - it's always helpful to see how others are solving similar challenges.

That said, I've already gone quite a bit deeper into this. I've thoroughly evaluated the SDK, and as you probably noticed, it ultimately uses the same APIs under the hood. For example, in the SDK on GitHubif you look at line 5412 onwards, you'll notice that it calls the same API.

So whether we're using the SDK or hitting the API directly, the volume of calls remains unchanged - and when you're dealing with 200k+ conversations a day, that's not exactly scalable.

@Daniel Ho, 

As you've rightly pointed out before - "we don't recommend calling the individual API iteratively for sweeping through all recordings in the system." I completely agree.

However, as far as I've seen, this API is the only source that provides complete and accurate recording metadata.

Is there any alternative you'd recommend that can return this level of detail without having to individually call the recording metadata API per conversation and get the desired sample metadata shared earlier

Appreciate your thoughts!

Check the API's I mentioned, these will get conversations in bulk and that will reduce the amount of API calls that you may be handling currently with the export API's you mentioned at the start. I have not used the export API's but seems they are not efficient in this aspect.

Hi @Vineet Kakroo,

Thank you for your response. Yes, your understanding is correct-I need just the metadata.

I have evaluated the SDK, and it indeed uses the same APIs. My main challenge is how to efficiently handle a huge volume of records per day on managing large-scale data retrieval using these APIs/SDK?

Thanks again for your help!

Hi @Vikas Shetty, I have a similar requirement and have done it slightly differently.
I have scheduled a daily export based on an interactions tab that captures all the possible information, baring the participant attributes. It is good for our purpose, but may not be suitable to your requirements.

In addition I have an API based solution that we run ad-hoc if required, especially to download bulk recordings. This process uses a combination of following Java SDK API;
postAnalyticsConcersationDetailsJobs
getAnalyticsConversationDetailsJob
getAnalyticsConcersationsDetailsJobResults
getRecordingBatchrequest
postRecordingBatchrequests
getConversationRecordingmetadata

With this I am able to download a months worth of recordings/data at a time and I believe you can use the above API's in combination to get to your specific requirements for 1 day. To avoid rate limit issues, I run the download process in batches of 10. As you are not going to download anything just reporting data, I am sure this would be much faster.
Hope this helps.

Hi @Daniel Ho,

Thanks for your suggestions. I'm aware of the Genesys AWS S3 export and we are currently using it. However, the metadata file generated through this export doesn't include all the details we need. For example:

• UserID is provided, but the username string is not included.

• QueueID is available, but not the queue name string.

• There's no information about the Division related to the call.

Because of these limitations, we considered using the Conversation Exports via the Analytics API and then attaching the recording metadata using the earlier mentioned API. Yes, I understand this results in a large number of API calls for a complete daily call data report.

Could you please suggest any alternative approach that avoids these excessive API calls? We do not require the media files, only the metadata.

sample metadata:
{
  "conversation_id": "5d6f338a-39c8-443c-a2b7-e3d2ef758567",
  "users": "garima balodi; vikas shetty",
  "date": "7/1/25 06:51 AM",
  "duration": "06:05",
  "direction": "Inbound",
  "queue": "InstaCCEngineering",
  "wrap_up": "dummy; Demo",
  "ani": "tel:+918***********",
  "dnis": "tel:+191**********",
  "transferred": "YES",
  "consult_transferred": "YES",
  "recording": "YES",
  "division": "Home",
  "disconnect_type": "External",
  "screen_recorded": "NO",
  "recordings": [
    {
      "recording_id": "9e6f7806-aeee-48ba-8088-be79ac14f9b5",
      "conversation_id": "5d6f338a-39c8-443c-a2b7-e3d2ef758567",
      "start_time": "2025-07-01T06:51:38.974Z",
      "end_time": "2025-07-01T06:57:20.354Z",
      "media": "audio",
      "media_subtype": "Trunk",
      "region": "us-east-1"
    },
    {
      "recording_id": "8030babc-6742-4757-9e57-3c421e00813b",
      "conversation_id": "5d6f338a-39c8-443c-a2b7-e3d2ef758567",
      "start_time": "2025-07-01T06:56:16.687Z",
      "end_time": "2025-07-01T06:56:43.607Z",
      "media": "audio",
      "media_subtype": "Consult",
      "region": "us-east-1"
    }
  ]
}

Thanks in advance for your guidance.

Hi Vikas,

In general we don't recommend calling the individual API iteratively for sweeping through all recordings in the system.

I can think of a couple of things:

• There is the recording bulk action API that will export recordings -- including both the recording asset and the metadata -- to an S3 bucket. See https://help.mypurecloud.com/articles/working-with-exported-recordings-in-aws-s3-bucket/ for details.  There's also a Glue+Athena reference example to search from the S3.
• If you don't need recording-specific metadata (e.g. recording start/end time, duration) -- since most metadata are found at the conversation level as you have the Analytics export -- you don't need that last step of recording metadata retrieval at all.  If you just need some confirmation that these recordings are captured, you can instead go looking for Recording Create audit event at the async Audit Event API.

Hi Team,

We are exploring ways to optimize the retrieval of daily CDR data and associated recording metadata for over 200,000 conversations using Genesys Cloud APIs, while staying within the API rate limits and improving performance.

1. Export Request:
   We initiate the export using:
   POST /api/v2/analytics/reporting/exports
   with the required parameters for <Interaction Search View> to submit the request to Genesys.
2. Export Status Check:
   After ~30 minutes, we check the status using:
   GET /api/v2/analytics/reporting/exports/<export_id>
   If the status is COMPLETED, we proceed to download the data.
3. Paginated CSV Retrieval:
   Given the volume and the Genesys rate limit of 2,500 rows per CSV, we anticipate needing to call:
   GET /api/v2/analytics/reporting/exports/<export_id>?pageNumber=1
   through to possibly pageNumber=100 or more to retrieve all data per day.
4. Recording Metadata Retrieval:
   For each conversation, we also need to retrieve recording metadata using:
   GET /api/v2/conversations/{conversationId}/recordingmetadata
   This could result in 200,000+ API calls per day.

• Is this approach acceptable within the current rate limits?
• Would you recommend any optimizations or batching strategies to handle this scale more efficiently?
• Is there a bulk API for recording metadata that could reduce the number of individual calls?