I’ve built a lot of integrations using Coda and Make (formerly Integromat) and it’s been great until this latest major release of features from Coda.
It usually worked pretty much instantly to Make to read a doc and find the correct rowId to update a information, for example. But what I face now is some sort of delay, like Coda’s taking a few seconds to make available to the API the line I just created.
I have to put a few “Sleep” modules between all the scenario actions and the final update back on Coda (sometimes, things like 8 seconds), otherwise it breaks with a 404, saying it can’t get a row with the ID of a line I just created.
Does Coda changed something on it’s API processing power lately?
Is someone else having this kind of issue?
Hi @hugo_assuncao - I’m not aware of any changes to how our API handles mutations, but I’ll ask around to see if anything has changed. The API documentation does include this information about consistency:
While edits made in Coda are shared with other collaborators in real-time, it can take a few seconds for them to become available via the API. You may also notice that changes made via the API, such as updating a row, are not immediate. These endpoints all return an HTTP 202 status code, instead of a standard 200, indicating that the edit has been accepted and queued for processing. This generally takes a few seconds, and the edit may fail if invalid. Each such edit will return a requestId in the response, and you can pass this requestId to the #getMutationStatus endpoint to find out if it has been applied.
I’m not very familiar with Make’s features, but if you could check the getMutationStatus endpoint in a loop that would be more reliable than sleeps.
I got the same issue, but the changes are not made with an api call, but in the Coda application. A user makes some changes, triggers a webhook, and the automation tool will retrieve the row data (passed as a parameter to the webhook).
If a user is adding/changes and triggering too fast, the automation tool is retrieving old information or get a 404 error.
So I also add a delay/sleep but this is feeling as an ugly solution. Might there be a more subtle solution on this case as well?
That’s the case in here too.
I have several applications built with Coda as database and use it’s data to trigger scenarios on Make (formerlly Integromat), but if I select a subset of data (say, apply a filter) and trigger the automation (which will read this doc), it returns a 404, since this last change hasn’t been made available through API.
I’ve read the documentantion on getMutationStatus endpoint, but found no use to implement it on Make, so I just have to wait a few seconds between making any changes and triggering the automation – or I have to send the data I want through the webhook URL (that works, but only for small chuncks of data).
I actually did’n implement a delay, or sleep function to it, instead I’ve set up a error handler, to show me the 404, as I’ve seen time varying between 5 and 20 seconds - it’s really strange.
For more complex use cases, I’ve built an application on Bubble.io, a no-code platform, which can handle more robust logic and a larger amount of data. In this particular case I had to move the project not only because of Coda, but also because Make has it’s limitations too (it was a workflow to get customer data from one software and create - and sign - multiple documents, so, a little bit too much for these two guys).
My solution in this kind of scenario (user updates data in the UI, triggers an outside server to read that data via Coda API), is similar in spirit to getMutationStatus.
Make a column with formula Modified(), and send it along in the querystring.
Read the row via API; if API row’s modification date < querystring modification date, wait a bit and try again
(Not experienced with Make so unsure if it can loop like this)
If you reverse the polarity of the integration you can make it darn near real time.
You need two things - a webhook trigger in QlikCloud and a custom pack that posts to the webhook. As data changes in the Coda table, it is almost instantly sent to Qlik via the Pack.
I use this technique with Firebase and MapBox and the performance is excellent.
Just to let Coda devs know : I encountered several cases where inserting rows through API (make), then searching for those rows (through make also) needed around 1 min of « sync delay » (45 sec is not sufficient to get the inserted data).
That is so long (and seems to be increasing). ==> Does that also seem « normal » to you ?
As I understand you can’t remove that delay, a way to get inserted row ids after executing Make’s modules would save a lot of complexity for no-coders that love Coda (As wall as a secured formula to get row ids in Coda docs ).
The delay seems to correlate with the size of the doc somehow. In an empty doc it seems to be almost instant.
I have some data over 4 months where I also calculate the API delay, I graphed it here. Y-axis is seconds. This is from a huge doc.
).
But anyway, you can