The Issue: Call to API leaves row values in blank despite having the JSON correctly written. Sometimes it works correctly, other times it doesn’t.
What I need by API call to do is: 1. edit one (or more) value in one row, 2. add a new row with new values
This is how my JSON looks like:
The first part (editing) is made without issue. However, when I add the new row, only one of the values is copied. The other two (highlighted in yellow) sometimes get copied and sometimes don’t.
Yesterday I did the action that uses this API call like 30 times and it always worked. Today, it has been failing every time I try.
Yeah you can, I do it all the time.
My comments in that other thread were in reference to the new Glide integration in Make, which doesn’t support it.
How are your mutations created?
Are you using the JSON Object column?
I have seen instances where this sometimes fails to return any result at all. Although when that happens if it is subsequently used in an API call, the call will fail. So perhaps not the issue here.
They are created through a Javascript column, I add the values that cannot pass as parameters to my code through a Template column and then I convert that to JSON through a Query JSON column. I had seen in previous forum entries that they use the JSON Object column but it says in the glide plugins page that it is deprecated.
It’s the Make JSON Object that is being deprecated. The JSON Object column will stay, and in fact is a replacement column for the former.
But anyway… are you 100% certain that you’re not passing empty values when it fails?
What you could do is add an extra step to your action sequence that writes the payload to a table, so you in effect create a log. Then you could examine what was sent with every API call.
In the screenshots I uploaded here, the JSON looked like that before clicking the button that triggers the action, so I assume that by that moment none of the values I want to add are empty. However, I wasn’t sure how to know if that information if actually the one that gets passed to my API call (in my frontend, before the button that triggers it I added a text value with my JSON and everything in it seems correct as well).
Tomorrow I’m going to add the extra step you mention to actually be completely certain that nothing is empty, though. Thanks
Hi again. I added the extra step of writing the payload and it does pass all the values. However, it is still failing.
To avoid possible issues with the way I have written my API call, I decided to split it in two: one that edits values and another one that adds a row, let’s call them A and B respectively. I first decided to add only one call and it worked correctly (I tried both with A and B). However, when I work with the two of them together, they still fail. Right now the issue is that in my first call (A) not all the values are getting edited.
I currently have it like this, I don’t know if I should write a wait condition between the two calls or something like that?
Hi, yes. However, I split it into two API calls like I said before and honestly I am not sure what happened later but it never failed me again, I didn’t need to add a wait condition or anything.
For what it’s worth, I was having somewhat similar issues recently. My scenario was typically as follows:
Call API Action, calling the Glide API with a batch of mutations, typically about 20-40, and a mix of add-row-to-table and set-column-values
Various other actions in a sequence
I had two issues:
firstly, it was really slow. After triggering the action, there was a 5-10 second delay while the action was running. My (unconfirmed) theory regarding that is that the Call API action waits for a response, and that takes time as the Glide API processes the payload and responds. Regardless of the cause, it made for a crappy user experience
the second - and more serious - issue was that every now and then one of the other actions in the sequence would apparently fail. I say apparently because I’m not 100% certain, but I debugged the hell out of it and couldn’t find any other explanation.
So what I ended up doing is dumping the Call API actions altogether and replaced them with a very simple and generic make scenario, which I call with the new Trigger Webhook action:
The webhook receives two parameters:
– AppID of the App that triggered the webhook
– JSON payload containing all the mutations that were previously sent via Call API
The Data store module just uses the AppID to lookup the Glide API Bearer token
And the HTTP module passes the entire JSON payload straight back to the Glide API
Since implementing this change about a week ago, both issues have evaporated and my Action sequences (I have about a dozen very similar ones) are running flawlessly.
Take all that as you like, but so far it’s been working very well for me