Launched: Coda API v1

You didn’t think we’d be in Beta forever, did you? :wink:

When we introduced our API capabilities (first via Zapier, and then via our Beta API offering), we wanted to make sure developers could maximize Coda’s powerful features with their third party applications and data sources. Since then, our product has changed a bit and we’ve received a lot of useful feedback on our API.

Today, we’re excited to introduce the official Coda API v1.

If you want to jump right to migrating your current API implementations, you can access our Migration Guide at

So what’s changing?

In addition to making the API simpler to use and more powerful, some other important changes include:

  • A new endpoint: Endpoints that modify docs now return a request id, which you can pass to to check if an update that was queued for processing has been applied
  • Endpoints for tables and views have merged: Previously, you had to use a separate endpoint to get or modify a view than you would for a table. In the v1 API, you can pass a view id to the shared /tables/ endpoint
  • Sections are now pages: Since we’ve launched pages and deprecated folders and sections, endpoints for folders and sections have been removed and consolidated into a new set of endpoints for pages. To find nested sections you previously had to make a request to a folders endpoint; now you can examine page objects for children and parent properties
  • Pagination is simpler: To get the next page of results, pass the nextPageToken from the previous page as the pageToken for your next request. There’s no need to pass any other parameters. (This is now the only way to get more results.)
  • And, v1beta1 should be replaced with v1 in your API URLs

Note that Zapier integrations and Cross-doc actions in Coda are indeed powered by the API, but no action is needed on your end to update such applicationsーwe’re taking care of that behind the scenes.

If you use the Google Apps Script, we recommend reviewing the Google Apps Script Migration section of the Migration Guide to plan your changes.

As stated in our Beta API documentation, we’re observing a 4 week (30 day) period to make changes before turning down our Beta API instance. We’ll be reaching out via email to affected customers next week and the 30 day migration period will start then. If you’ll require more time to make changes, please contact us at Now that we’re out of Beta, the V1 API will be supported for at least 6 months (through at least January 15, 2021) and we’ll provide at least 3 months notice before making breaking changes on or after that date.


I’ve been using cross-doc syncing pretty heavily and I’ve been running into the 125MB doc size limit on API calls quite a bit. Are you increasing that limit as part of this v1 release as well?

1 Like

We definitely hear your pain on this. We didn’t address that directly as part of this release, but we’re working on internal changes to shrink the size of all docs so that fewer hit the limit.


That’s exciting! Unrelated, but are there plans to increase the 10,000 row limit per doc?

We didn’t address that with this release but we are hoping other doc size work that’s underway may make it possible to raise some of these limits.


One more question! Do you plan to add more triggers to Zapier? Updated row (as opposed to new row) would be incredibly helpful. Right now we have to use all kinds of temporary tables to simulate this.


I just noticed this — any reason there’s this inconsistency in doc ID (no prefix) vs other ids (folder fl- prefix, grid/table prefixes etc)?

Thanks for the suggestion, we’re exploring with Zapier how we might be able to accomplish this.

Docs are just special… most of our other objects have specific prefixes. :eye::lips::eye: