Genesys Cloud - Developer Community!

Hi everyone,

I am planning to use the /api/v2/recording/jobs API to bulk-archive recordings for a client.

I've been looking through the documentation but haven't found a recommended limit or best practice regarding the maximum size/volume a single job should handle.

For context, the client generates roughly 300GB of recordings per month.

• Is it feasible to process an entire month (300GB) in a single bulk job?

• Are the job limits constrained by total data size (GB), or is there a hard limit on the number of recording/conversation IDs passed per job?

If a single month is too large, what is the recommended batch size per job?

Thanks in advance!

Hi @Chanin Srisathian, hope you are doing fine.

From my experience, theres no recommended limit for a recording bulk export. What I've experienced is that some problems may occur with recordings when the export takes too long to complete (it could be related to the quantity of recordings or even the total size) as the download URL may expire after sometime (if the export hadnt ended, errors or broken files may appear).

What I did as "best practice" is to limit the number of recordings exported each time (from previous research around the Community, that I adopted myself, people do it around 100), with this you try to minimize the chance of the downloading URL to expire and blank/bugged files to appear.

Hope to have been able to help you in some way!

------------------------------
Diego Halter
------------------------------

Hi Diego,

Thanks for the reply!

You mentioned recording bulk exports and URLs expiring if the process takes too long. Do you happen to know if these same issues or performance bottlenecks occur when archiving recordings?

I am specifically using the /api/v2/recording/jobs endpoint with the archive action, so I'm wondering if the same size limits and risk of errors may apply to that process as well.

No Problem Chanin!

I think it was a little late and I just thought about the problem that I had when exporting and completely ignored the "archive" part 😂.

From my understanding, when the api action is to archive, it doesn't gerenate urls to download/export, so it wont have an expiring time and you won't face the same problem I did.


@Alex Sander Felicio Hi Alex! I tried exporting some months ago without limiting it and found that problems could occur if the download link had expired (60 minutes was the maximum time), so by the time I just limited it to a value that could have the export completed before the url expiration (for me I did with batches of 100 recordings, as I found another guy with the same problem here on community).

Hi! Thanks for sharing your experience. Just to confirm: do you usually limit the number of recordings per bulk export to avoid API limits, URL expiration, or broken files? And do you process the exports in smaller batches, for example around 100 recordings at a time?

Hello, @Chanin Srisathian

I have not seen a public Genesys recommendation that defines a specific bulk recording job size in GB, such as "300GB per job is supported" or "X GB is the recommended maximum."

For this API, I would think more in terms of the number of conversations/recordings matched by the conversationQuery, the date interval, and how easy the job is to monitor and retry. A 300GB month may work in some environments, but I would not make the first production run an entire month in one job.

My recommendation would be to start with smaller time-based batches, for example one day or a few days, validate the job result, and then increase the interval if the jobs are completing cleanly. The job status response should help you monitor values like total conversations, total recordings, processed recordings, failed recordings, and percent progress.

If the monthly volume is around 300GB, I would personally prefer splitting it into daily or weekly jobs. It gives you better control, easier retry logic, and less impact if one job fails or gets stuck.

I would also avoid passing a very large list of conversation IDs if you can filter by interval, queue, media type, or other conversationQuery criteria instead. Large explicit ID lists can become harder to manage and may run into request/payload practicality limits, even if the main job processing is asynchronous.