Reached limit of 50 requests per script invocation. Best way to go around this?

[Martin_Malinda]

Hello!

Here’s what I’m doing at the moment:
Each week I’m generating feedback forms for all active classes. Each form is unique and therefore I’m using the TypeForm Create API to construct the forms from my data in my Airtable.
There’s 32 classes currently and each class requires 2 requests - 1. to create the form and 2. to add a webhook to it.

That’s 64 requests which exceeds a quote of 50 request per script invocation.

What’s the best way to go forward here?

• I can split the script in two, create forms in first script, add webhooks in second script. It will lead to some code duplication:(
• Set up a separate automation run for each form. 32 requests in each run, then 1 request per each automation triggered for every row. That’s +33 automation runs / week
• Just handle this in a script running elsewhere than Airtable… no limits there. Easy for me, but makes it harder to maintain once I leave the project. Someone needs to be able to run and change the CloudFlare workers / Netlify Functions or whatever would be used for this.
• Use Zapier? Maybe Zapier has more generous request limits?

Some solution would scale only to a certain degree. If the number of classes goes over 50, even the first “half” of the script would stop running.

How do you reason about these limits? To be honest it’s a little bit of a headache as I’m already trying to figure out the best algorithms and this adds an another layer of complexity. It would be so nice if Airtable just invoiced me for some minutes of computation power in the style of AWS etc and lifted any sort of hardcoded quotas.

Thanks for any tips on this :pray:

[ScottWorld]

I don’t know JavaScript so I can’t help you with your scripting question.

However, to answer your question about Zapier, I highly recommend NOT using Zapier by using Make instead.

Make is significantly cheaper than Zapier, and it is also a zillion trillion times more powerful than Zapier. I regularly switch my clients from Zapier to Make, and they’re blown away at what they can FINALLY do that they were never able to do with Zapier. Make can do things that Zapier can only dream of doing.

The major downside with Make is that there is a very steep learning curve to understanding the product, but once you understand it, you will be sailing high! :sailboat: :smiling_face_with_sunglasses:

p.s. For companies that have a budget to hire an expert Airtable/Make consultant, I’m also available to help people with their Make scenarios.

[TheTimeSavingCo]

Martin_Malinda:

What’s the best way to go forward here?

Ha, I think we’re going to need to define “best” here my dude

I feel like “Best” in terms of your time spent would probably be the +33 runs / week thing as you’d be able to get that done in 5 minutes.

How many of the available 50k automation runs are you using on average per month? If you’ve got a lot of spare runs I’d just do this I think

[kuovonne]

Martin_Malinda:

That’s 64 requests which exceeds a quote of 50 request per script invocation.

What’s the best way to go forward here?

There are various alternatives.

Are you limited to using an automation script? If you use Scripting extension, there is no limit on the number of requests per script. You will need a human to push the button to run the script, but you might be able to tie the button push in with a different workflow.

How many other automattions are you using per month? 33+ automations per week is a fraction of the 50,000 automation runs a pro workspace gets per month. This will probably be the easiest to scale.

Since you are concerned with maintenance once you leave the project, I recommend staying inside Airtable. Even if you have to split the script into two with some code duplication, it will be easier for someone else to understand what is going on if there is only one platform/login to deal with.

[Bill_French]

Martin_Malinda:

There’s 32 classes currently and each class requires 2 requests

Even if you break this into two separate scripts, it hits the ceiling at 51 classes, right?

I think @kuovonne is on the right track -

kuovonne:

If you use Scripting extension, there is no limit on the number of requests per script.

Automations are ideal for eliminating human actions for repeating and often time-centric processes. I don’t think this falls into that ideal use of automations. Correct me if I’m missing something, but these processes are intended to run once for a given week and ideally you (the maintainer) needn’t worry about them. However, wouldn’t it be easier to run a single script extension once a semester, or once per year?

I get it - you want to get humans out of the business of managing processes, but this could be an aggregate process that could easily scale to thousands of classes and may actually benefit from a human task to configure a giant swath of forms.

[Martin_Malinda]

Correct me if I’m missing something, but these processes are intended to run once for a given week and ideally you (the maintainer) needn’t worry about them. However, wouldn’t it be easier to run a single script extension once a semester, or once per year?

This is an interesting idea :bulb: . Adding certain prompts to the form generation process would perhaps help maintenance so the script would not have to be manually adjusted if title or other things were to change. So that would justify a manual action.

I’ll keep the workflow to be generated on weekly basis for now. That approach has some potential benefits as well, as the form can react to some data changes during the year (changes in teachers and such) so it feels safe for that reason.

But even a button push on weekly basis isn’t really a bad thing if it allows some extra configuration. Thank a lot @Bill.French and @kuovonne :thumbs_up: I’m seeing some nice paths forward now.