API returning old data

Developers Central
1

Hi, I’m trying out the API.
I’m calling two APIs.

  1. I update a certain row.

  2. I get a row from a view.

After (1), when I call (2), it returns the old data. When (1) returned 200, is it just adding the task to your queue and handle it asynchronously?

Is there any way for me to make sure I get the latest data with (2)?

Thanks

2

“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. In the future, we may provide a way to acknowledge edits.”

This does appear to be an async issue, I got around this by adding a 3 second delay to my next call, the delay time would vary on several factors however, so not sure if there is a consistent delay that will work.

2 Likes
3

Oh I definitely missed that part from the documentation.
Thanks for the tip :slight_smile:

4

This also applies to changes made by users in the GUI: it takes a little while (up to about 10sec in my testing I think?) before that new data is accessible by the API (API just returns stale data in the meantime).

Are there any plans to speed up this lag time between API edits and GUI edits, or is the API expected to stay less realtime than the GUI? I think the slower API is a reasonable design decision, it just messes with one of my use cases:

  1. User makes changes to a row in a detail view, clicks a “Generate PDF” button
  2. That button opens a URL with the row ID in a querystring
  3. A script pulls the row from the API using the ID in the querystring and formats it for pretty printing (along with making a few other calculations / calls to other outside services

I suppose in my case I could try passing the entire row’s columns in the querystring, wouldn’t be the end of the world… but maybe hard with serialized data (there are some multi-select lookups involved)

5

@Joshua_Upton already quoted the relevant part of the API documentation, but to give some more context on this, the delay is dependent upon a number of factors such as the size of your doc and Coda’s overall service utilization. Essentially, to support relatively fast lookups on docs, it takes some time for changes to a doc to get saved (“snapshotted”, as we call it internally) into a cache that is then read by the API — this might include something like recalculating an entire doc if, say, a core formula in the doc is changed.

We have discussed an alternative architecture to our API that would support realtime updates, but it would be a lot of work and possibly be prohibitively expensive for us to offer. A change we’re more likely to make shorter term is to have the update be blocking, or a return a URL you can ping that will tell you when your change has been applied.

In the meantime, you can try and get this working yourself by writing the current timestamp into a separate table. You can then poll that value using the API and wait until the timestamp returned by the API is equal to or newer than the value you wrote in, which would indicate that any updates to the API made before that have already been processed.

2 Likes