Can only send 15 mutations every 1000ms

I suspect that you are simply seeing better error reporting on an existing limit that Airtable has not clearly published or enforced.

Although I haven’t seen a published rate limit in Scripting App, both automation script actions and custom apps have a rate limit of 15 mutations per second. It is reasonable to assume that scripting app probably has a same rate limit.

My experience and the experience of the user in this thread also support the idea of a 15 mutations/second rate limit in scripting app.

As for why you didn’t see the error before, it could be that Airtable isn’t always consistent in reinforcing rate limits, per this post about rate limits and the REST API.

With the increased number of mutations due to the release of automations, Airtable may have decided that they need to enforce rate limits more.

As for workarounds, you could write your own code to throttle your calls to 15/second using the setTimeout function, as described in this thread. It might be difficult to get 15 calls/second, but you should be able to get more than you would get with awaiting every call.

Even though it takes time to wait for records to update using “await”, there is potential for records to get updated inaccurately if you don’t use “await” before calling updateRecordsAsync. I’ve seen this firsthand in my early Airtable scripts, where I forgot to use “await” and things got messed up as a result.

When you say that you process large amounts of data, how many records are you updating at a time? Using updateRecordsAsync, Airtable can process updates in groups of up to 50, which actually is much faster than updating records one at a time with updateRecordAsync. If you build an array containing all of the necessary updates in advance, a simple loop can pass those to updateRecordsAsync in groups of 50 (using “await”) for very efficient processing. Several hundred records can process in a matter of seconds.

Even though it takes time to wait for records to update using “await”, there is potential for records to get updated inaccurately if you don’t use “await” before calling updateRecordsAsync. I’ve seen this firsthand in my early Airtable scripts, where I forgot to use “await” and things got messed up as a result.

When you say that you process large amounts of data, how many records are you updating at a time? Using updateRecordsAsync, Airtable can process updates in groups of up to 50, which actually is much faster than updating records one at a time with updateRecordAsync. If you build an array containing all of the necessary updates in advance, a simple loop can pass those to updateRecordsAsync in groups of 50 (using “await”) for very efficient processing. Several hundred records can process in a matter of seconds.

@Sam_Cederwall Aren’t you already updating your records in batches of 50? You stated that you are using updateRecordsAsync (with an s) in your initial post.

You could further break up your batches into sets of 15, and use setTimeout to spread out those batches. This is what I was referring to in my prior post that suggested throttling your calls to 15/second.

You can update 50 records in one mutation. You can submit up to 15 mutations in one second. Thus, you can update 750 records in one second.

For example, say you have 50,000 records to update:

Break the records down into sets of 66 sets of 750 (and one set of 500).
Break each set of 750 into 15 batches of 50.
Submit the first set of 750 records, using 15 synchronous calls (no await) to updateRecordsAsync with 50 records each.
Wait one second.
Submit the second set of 750 records.
Wait one second.
Continue on until all 67 sets are submitted.