Server-side updates still would count towards your updates the way they show in your workflows I guess.
Assuming you use a scheduled trigger like this.
What shows in my usage is 10 updates.
So going by your example, that would be 30k for 30k “edit row”.
This post is more relevant for when you do API calls.
The loops don’t cost you any updates, but the edits will.
When you look at a workflow run log, it’s pretty easy to calculate how many updates were used.
I would assume this is only partially true, because if you call the API from an http module then it would consume 0.01 updates while updating in bulk?
If you’re using the V2 API, then yes.
But if you’re using the V1 API, then it’s one update per mutation.
This has the potential to be game changing! As my app pretty much completely runs on API calls, there is very little app interaction
Can’t wait till it’s available for Glide Tables.
Wait…IS this going to be available for glide tables?!
Here.
Net/net: it is a penny ($.01) per update for a Big Table row done through the API and $.00 if done within the app (e.g. have the row open in a screen and updating the date via a Set Col Value action). I think that is correct.
Yes, on non-Enterprise plans.
But you can’t do it with 30k rows, if you ever need something like that.
In-App updates to native tables are only counted on legacy plans now, including enterprise.
Once this is live for regular tables as well, I can finally change from my legacy plan, as the only reason i’ve been holding onto it is I get double the updates from API than current plans and for half the price. Cheers
This isn’t true based on the math above, its 0.01 UPDATES per mutation, not dollars. Only through the V2 API. Someone can correct me if i’m wrong
Best place to confirm pricing is our API documentation (URL)
Tell me, will there be a price change for using Call API via Action?
Just when changing one row or deleting one row, it still costs at least 1.01 actions
No, updates for Call API are not being updated due to this change
From https://apidocs.glideapps.com/api-reference/v2/general/introduction#pricing
What does “your commit your stash” mean?
Just my guess, “commit” might mean you actually do something with the stash, not just stashing data to it.
Those actions include:
Is there an ETA for this to go live for the Glide Tables?
@DJP I wanted to test the API on a copy of the table but then I realised in time that for the duplicated table the ID is the same, bearer is the same, column names are the same, and my test PUT request ended up targeting first 10 records of the wrong table.
With previous API we had to include app ID which I guess would force the right table to be targeted.
What are the possible ways to determine the right table to be targeted with API 2.0 when multiple copies of a table exist in one team?
Can you send me the table names and the app IDs? I can take a look
