CALL API skipping mutations

I am using call API to update a current timestamp in multiple rows at the same time.

I just realized that CALL API is skipping mutations sometimes. Any idea why & how I can track this? This is using Glide builder. I will test from the app as well.

I would start by checking the action log run history to see what was actually sent.

Thank you @Darren_Murphy great tip. Will check this immediately, the next time this happens.

Do you know any reasons a mutation can be skipped (although the total count is only 3-4)

When we roll this out, it will have 300-400 mutations per call API

How are the mutations prepared?
I have seen unexplained failures when using the JSON Object/JSON Template columns in conjunction with Trigger Webhook, so I don’t have absolute confidence in them. I’ve also found that Call API can be very slow when sending large numbers of mutations to the Glide API, and so I tend to avoid it as well.

For bulk mutations (which I do a lot of), I’ve found the most reliable (and fastest) approach is to prepare the mutations with normal Template columns, and send them via Make as a webhook.


That is a bit worrying now for me…

Mutations are prepared using JSON Object column and then lookup etc…
There is a button that triggers the Call API and the body contains the mutations.

We go to a partner and pick up 200 items… I want to set a timestamp for every row of the pickup action. Previously we stored a pickup global timestamp & then each item can have a computed pickup value etc…

But now I want to set the pickup timestamp in the row as a basic column.

I will be tesing this with a larger number of rows later this week… but would do you have more insight on the time expected for 300-400 mutations? and the cost of sending them to MAKE instead?

I was hoping we don’ thave to go through MAKE since Glide has a Call API

The problem with the Call API action is that it blocks while waiting for a response from the Glide API, so if you’re sending a large number of mutations the delay while the Glide API processes them and responds can be quite significant. Which results in a crappy user experience.

When you send a webhook, it’s basically “send and forget”, so from an end user perspective it’s a much better experience.

In terms of Make operations cost, as long as you batch them and don’t send one by one, then the cost is negligible.


Let me check what the delay is. Its better for us that the app waits for the response before proceeding. Lets hope its not minutes!!