The Coda API is a RESTful API that lets you programmatically interact with Coda docs:

• List and search Coda docs
• Create new docs and copy existing ones
• Share and publish docs
• Discover pages, tables, formulas, and controls
• Read, insert, upsert, update, and delete rows

As we update and release newer versions of the API, we reserve the right to remove older APIs and functionality with a 3-month deprecation notice. We will post about such changes as well as announce new features in the Developers Central section of our Community, and update the API updates doc.

Our Getting Started Guide helps you learn the basic of working with the API and shows a few ways you can use it. Check it out, and learn how to:

• Read data from Coda tables and write back to them
• Build a one-way sync from one Coda doc to another
• Automate reminders
• Sync your Google Calendar to Coda

Coda's REST API is designed to be straightforward to use. You can use the language and platform of your choice to make requests. To get a feel for the API, you can also use a tool like Postman or Insomnia.

This API uses a base path of https://coda.io/apis/v1.

Each resource instance retrieved via the API has the following fields:

• id: The resource's immutable ID, which can be used to refer to it within its context
• type: The type of resource, useful for identifying it in a heterogenous collection of results
• href: A fully qualified URI that can be used to refer to and get the latest details on the resource

Most resources can be queried by their name or ID. We recommend sticking with IDs where possible, as names are fragile and prone to being changed by your doc's users.

List Endpoints

Endpoints supporting listing of resources have the following fields:

• items: An array containing the listed resources, limited by the limit or pageToken query parameters
• nextPageLink: If more results are available, an API link to the next page of results
• nextPageToken: If more results are available, a page token that can be passed into the pageToken query parameter

The maximum page size may change at any time, and may be different for different endpoints. Please do not rely on it for any behavior of your application. If you pass a limit parameter that is larger than our maximum allowed limit, we will only return as many results as our maximum limit. You should look for the presence of the nextPageToken on the response to see if there are more results available, rather than relying on a result set that matches your provided limit.

To fetch a subsequent page of results, pass the pageToken parameter. Set this parameter to the value given to you as the nextPageToken in a page response. If no value is provided, there are no more results available. You only need to pass the pageToken to get the next page of results, you don't need to pass any of the parameters from your original request, as they are all implied by the pageToken. Any other parameters provided alongside a pageToken will be ignored.

Doc IDs

While most object IDs will have to be discovered via the API, you may find yourself frequently wanting to get the ID of a specific Coda doc.

Here's a handy tool that will extract it for you. (See if you can find the pattern!)

The Coda API sets a reasonable limit on the number of requests that can be made per minute. Once this limit is reached, calls to the API will start returning errors with an HTTP status code of 429.

These are the current rate limits. They are subject to change at any time without notice. For robustness, all API scripts should check for HTTP 429 Too Many Requests errors and back off and retry the request. Limits apply per-user across all endpoints that share the same limit and across all docs.

Reading data (with the exceptions below): 100 requests per 6 seconds
Writing data (POST/PUT/PATCH): 10 requests per 6 seconds
Writing doc content data (POST/PUT/PATCH): 5 requests per 10 seconds
Listing docs: 4 requests per 6 seconds
Reading analytics: 100 requests per 6 seconds

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.

Similarly, when you get doc data from the API (rows, pages, columns, etc), the data you receive comes from the most recent "snapshot" of the doc, which might be slightly stale relative to the data you observe in your browser. If you want to ensure that the data you receive is up to date and are ok getting an error if not, you can pass this header in your request: X-Coda-Doc-Version: latest. If the API's view of the doc is not up to date, the API will return an HTTP 400 response.

Coda exposes a number of "volatile" formulas, as as Today(), Now(), and User(). When used in a live Coda doc, these formulas affect what's visible in realtime, tailored to the current user.

Such formulas behave differently with the API. Time-based values may only be current to the last edit made to the doc. User-based values may be blank or invalid.

We make the Coda API available to all of our users free of charge, in both free and paid workspaces. However, API usage is subject to the role of the user associated with the API token in the workspace applicable to each API request. What this means is:

• For the #createDoc endpoint specifically, the owner of the API token must be a Doc Maker (or Admin) in the workspace. If the "Any member can create docs" option in enabled in the workspace settings, they can be an Editor and will get auto-promoted to Doc Maker upon using this endpoint. Lastly, if in addition, the API key owner matches the "Auto-join email domains" setting, they will be auto-added to the workspace and promoted to Doc Maker upon using this endpoint

This behavior applies to the API as well as any integrations that may use it, such as Zapier.

To help you get started, this documentation provides code examples in Python, Unix shell, and Google Apps Script. These examples are based on a simple doc that looks something like this:

Python examples

These examples use Python 3.6+. If you don't already have the requests module, use pip or easy_install to get it.

Shell examples

The shell examples are intended to be run in a Unix shell. If you're on Windows, you will need to install WSL.

These examples use the standard cURL utility to pull from the API, and then process it with jq to extract and format example output. If you don't already have it, you can either install it or run the command without it to see the raw JSON output.

Google Apps Script examples

Google Apps Script makes it easy to write code in a JavaScript-like syntax and easily access many Google products with built-in libraries. You can set up your scripts to run periodically, which makes it a good environment for writing tools without maintaining your own server.

Coda provides a library for Google Apps Script. To use it, go into Resources -> Libraries... and enter the following library ID: 15IQuWOk8MqT50FDWomh57UqWGH23gjsWVWYFms3ton6L-UHmefYHS9Vl. If you want to see the library's source code, it's available here.

Google provides autocomplete for API functions as well as generated docs. You can access these docs via the Libraries dialog by clicking on the library name. Required parameters that would be included in the URL path are positional arguments in each of these functions, followed by the request body, if applicable. All remaining parameters can be specified in the options object.

In an effort to standardize our API and make it accessible, we offer an OpenAPI 3.0 specification:

• OpenAPI 3.0 spec - YAML
• OpenAPI 3.0 spec - JSON

Postman collection

To get started with prototyping the API quickly in Postman, you can use one of links above to import the Coda API into a collection. You'll then need to set the appropriate header and environment variables.

We do not currently support client libraries apart from Google Apps Script. To work with the Coda API, you can either use standard network libraries for your language, or use the appropriate Swagger Generator tool to auto-generate Coda API client libraries for your language of choice. We do not provide any guarantees that these autogenerated libraries are compatible with our API (e.g., some libraries may not work with Bearer authentication).

OpenAPI 3.0

Swagger Generator 3 (that link takes you to the docs for the generator API) can generate client libraries for these languages. It's relatively new and thus only has support for a limited set of languages at this time.

Third-party client libraries

Some members of our amazing community have written libraries to work with our API. These aren't officially supported by Coda, but are listed here for convenience. (Please let us know if you've written a library and would like to have it included here.)

• PHP by Daniel Stieber
• Node-RED by Mori Sugimoto
• NodeJS by Parker McMullin
• Ruby by Carlos Muñoz at Getro
• Python by Mikhail Beliansky
• Go by Artur Safin

Coda docs are foundational, top-level collaborative projects that contain pages. The API lets you list and search your docs to obtain basic metadata like titles and ownership information.

This API lets you manage sharing and permissions for your docs.

Coda docs can be published publicly and associated with categories to help the world discover them. This API lets you manage the publishing settings of your docs.

Pages in Coda offer canvases containing rich text, tables, controls, and other objects. At this time, this API lets you list and access pages in a doc.