Google API: Running Apps Script

Hi all,

Brief: I am trying to use the Google API to run a script on Google Apps Script (GAS) from a scripting block. Has anyone accomplished this? I read through this thread and decided to pull data into GAS from the Google side, but my client wants me to handle it from Airtable.

Full Explanation:
I am new to Airtable and am developing a script that will scrape a website for video metrics. I saw in Airtable’s docs that direct DOM manipulations allowed in vanilla JS are excluded, so I decided to stick with a script I already had in GAS to perform the task.

I saw Bill’s in-depth response at the link above and decided to run the processes from Google for simplicity, as the Airtable API is a lot nicer to work with (i.e. pulling data into GAS) than pushing data to GAS from Airtable using the Google API, which requires Oauth2.

The group I am building the project for, however, wants me to make an API call to GAS from Airtable, call Urlfetchapp in GAS, and send the data back to Airtable to finish table manipulation there. They are claiming that they want as much of the code to be in Airtable so that they can use Airtable’s UI wherever possible. I have spent some time banging my head on the wall trying to get Oauth2 set up with the Google REST API, since I can’t use the gapi library (would need to use some of the workarounds discussed here and the library is likely too big for those). After that, I considered working directly with the Oauth2 endpoints as described by Google here, but that appears to require DOM manipulation if I am to avoid CORS issues. Sigh.

What I see as my options:

  1. Find an alternative to Urlfetchapp in order to perform the scrape without worrying about the Google API. Open to any free suggestions here on how to scrape from Airtable/any nice APIs to use.
  2. Insist with the client that doing all of the work from GAS will be cheaper/faster/easier. I assume the Airtable UI component they are interested in is the “add actions” option in the scripting block; their arguments seems to be that they want to filter table data in different ways without having to contact me to edit the script each time.
  3. Mess around with the gapi library and see if I can get it working. As stated above, I am guessing it is too large, but I could be wrong.
  4. Shoot my shot working with the Oauth2 endpoints, attempting to work around CORS issues by setting the appropriate Access-Control-Allow-Origin headers in the script’s Google Cloud project so that I can avoid form creation/DOM manipulation.

I would greatly appreciate if someone with more Airtable experience could chime in here. I saw that custom blocks – now Airtable apps? – might be the way to go, as mentioned by Bill on the aforementioned thread. Not confident with React, so I would like to avoid this if possible.

Thank you!

Hi JB, and welcome to the community!

Yes - many times. Lots to share but I don’t have time to write it today - call me as soon as you can at 970-389-3126 before someone else does. :wink:

1 Like

Thanks for the help earlier, Bill.

For any future readers, Bill and I discussed deploying my script as a Web App and using webhooks (doPost()) to get the job done, which is working for me.

Unfortunately, this thread discusses the limitations of this approach, namely, that fetch’s inability to handle redirects means that POST requests will fail even if the script runs:

Bill: I assume this means I have no choice but to use the Airtable API to update the table from my script, since there will be no return object?

I believe this is an accurate statement given that an oAuth-based API call from the script action is not possible and any return values from the Google Apps Script webhook is not possible. Note that return values do work fine in Airtable fetch calls if it’s not a Google Apps Script webhook server you are calling. This includes other Google SDKs such as Maps, etc. As far as I know, the inability to follow redirects is only an issue with Google Apps Script web services.

Another risk factor (for other readers) that we discussed is the possibility that the volume of actions could exceed the monthly quota. Just sayin’ …

All of these challenges conspire to intimate it may be better in some cases to use pure script triggers in Google Apps Script and forget about Airtable script altogether. One advantage of this approach is to sustain all integration logic separate and apart from Airtable in case you ever need to change database horses.

1 Like