I was working on translating the metadata of media assets (Alternate Text and Title) to a new locale using DatoCMS CMA. I have around 16,000 assets and faced a few issues during the process:
OpenAI returned a 429 status code (Too Many Requests).
I attempted batch processing with a batch size of 100 and a 1000ms delay, but encountered a 500 status code while processing the 34th batch (3,400 images).
Doubts & Questions:
What is the recommended rate limit for updating media assets via DatoCMS CMA?
How many media assets can be updated at once without hitting API limits?
Is there a better approach to handle large-scale metadata translation efficiently?
Should I introduce a longer delay between requests, or is there an alternative API optimization method?
Has anyone successfully handled bulk media metadata updates without hitting rate limits or server errors?
Can you email us at support@datocms.com the request ID (will be in the response headers of your request) that we returned a 500 for you so we can take a look at it?
On the CMA, the basic limit to remember is 60 requests per 3 seconds. You can send all 60 requests, wait 3 seconds, and then send another 60. Or you can send 20 per second. Either way, however many youāve used, the server will grant you 60 total requests every 3 seconds (they donāt overflow; you canāt ever have more than 60 max at a time).
You can use a library like p-queue, limiter, bottleneck, etc. to help with that. Generally I like to add a margin of safety, like limit it to maybe 50 requests per 3 seconds (or ~16 a sec), just to account for network jitter.
You can (optionally) also read our returned X-RateLimit-* headers (documented on that same page) to know how many requests you have left in the current 3-second window, and when theyāll refill next. You only need to do that if you want to be able to dynamically scale your requests up and down based on the server responses, but practically speaking, just sending 60 every 3 seconds should get you the same result. You can also only look at the headers if you get a 429, and then wait however long X-RateLimit-Reset says toā¦ or just wait 3 seconds.
Some of the operations may take longer than 3 seconds to complete our our side, but Iām pretty sure that you donāt have to wait for each operationās completion, just its receipt ā i.e., you can keep sending 60 / 3 seconds regardless of how long any individual request takes to resolve.
My suggestion is to use a library to help with all that so that you can maximize throughput while respecting rate limits. You can also write your own with timeouts and Promises.all(), etc., but the queue management over thousands of requests can get pretty complicated, especially if you need to manually manage errors & retries.
This is something that many customers have asked about over time, so maybe we should make an example implementation of a ārate-limited parallelized bulk update operationā. I have it on my list and Iāll try to show one next week.
Hope that helps in the meantime, but please do feel free to email us if you need more specific guidance!