Need help with an approach with fetching and editing data using Glide APIs

Hello fellow gliders,

I need some help with my approach, more some suggestions on best practices. This is with Glide APIs from a Zap.

I have a scenario where there are multiple tables involved, and a few of them have 1-many relation, so I cannot update the table using relationships through Glide actions. Hence taking the API route.

On click of a button, I do a couple of steps like adding a row, triggering a webhook to send multiple emails, etc., I now trigger another webhook to fetch rows from a particular table. Since these are Glide tables, I cannot write a SQL with WHERE condition to only fetch the rows I need.

Now I need to filter a subset of these rows based on values of 3 columns and I send those steps through the webhook which then needs to be updated for a certain set of columns (eg., set the email sent column to True and so on).

In order to filter the required subset of rows,

One option would be to use a filter in Zap and then Update the rows - Should I use a loop first and then apply filter and then edit the record, or wIll just a filter act as a WHERE condition giving me back the required rows.

Another option would be to write a “Code by Python” step in Zap, take the output of get rows, filter out the required rows. But I don’t see an option to send the entire output of get rows as they are shown as each column with values from the table. Something like this

My doubt is, am I missing some evident approach and trying to take an unnecessarily long route?

A snapshot of my Zap,

I know it sounds a bit confusing as I’ve explained it in an abstract manner. still hope it’s understandable. :blush:

Disclaimer: I’ve never used Zapier, and I know next to nothing about it (except that it appears to have a horribly clunky & cumbersome looking interface).

I am however, reasonably proficient with Make, Apps Script and using both to work with the Glide API.

What I generally do in cases like this is use a Helper Table to prepare all of the mutations I need, then bundle them up into a single JSON Payload, send that to Make via a Webhook, and then have Make post back to the Glide API. Because the mutations are prepared inside the Data Editor, it’s easy to apply filters so that you only update the rows that need updating.

It’s not simple - although not exactly rocket science either - and every use case is slightly different, but in my experience it is the best approach.


Thanks @Darren_Murphy for sharing your approach. Let me think on those lines, or see if I can tweak the business process so that one manual button click will solve quite some data resets.

That is definitely a good approach @Darren_Murphy ! I built my JSON Payload on Glide editor and send it to Zapier and perform updates on multiple tables. I used Code By Zapier to build them as dictionaries first and then invoke Glide APIs. No need for explicit looping as the dictionary response handles multiple rows automatically. Thanks again!


Just curious here, what’s the advantage of using Zapier over Make these days?


Good question @ThinhDinh :grin:

Honest answer is: probably I need to check out Make, especially the way it calculates operations. When I started out with Make sometime back, figuring out how my monthly quota got over so fast without doing much is something I never digged into. So I became skeptical to use it. Even before Make I tried Zapier when I started out with No Code, atleast from a Billing perspective it was quite straight forward. But it lacked a lot of flexibility which is why I moved to Make in first place.

I’ll take this as a reason to spend time understanding Make’s quota stuff, as it’ll be a good thing to know I suppose.

1 Like

Make’s way of calculating is the same as Zapier as far as I aware (1 module run = 1 operation), but the flexibility is what makes me use Make.

n8n is another option, doesn’t count each module run like Zapier or Make, a scenario run as a whole is the level they count, regardless of how many modules you use, but I haven’t calculated to see if their pricing and limit makes more sense than the others.


Thanks @ThinhDinh . Probably I should also start going back to Make. I shall take a quick check n n8n too.


Please don’t hesitate to let us know if you need help. I use Make a lot for my work.


Sure, will do. Infact, for one of my side hustle ( a free community app that I’m building), I used Zapier. Probably I shall change it to Make.Thanks for all the help!


This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.