We have been spending some time recently building out a RESTful API for Coda docs. We’ve sent it out to a few alpha testers and now we wanted to open it up to the broader community here.
The Coda API exposes a number of actions to make it easy for you to bring data in and out of existing tables within Coda doc. You’ll also have the capability to list and search Coda docs, discover sections, folders, tables, formulas, and controls.
DISCLAIMER: This API is still in beta. Before we publicly launch, we are likely to make major (read: breaking) changes. This is so we can minimize the need for breaking changes after we launch.
If you’re not scared away by our disclaimer and you’re still interested in building something with the API, fill out this survey, and then we’ll send over materials to get started.
Hey @preeyanka
I’m very interested, but I’m afraid it would be to techy for me. What do you think? Shall I try it anyway? Perhaps a noobish point of view would help?
Right now we’re looking for early adopters who are already somewhat familiar with building things with APIs. However, when we publicly launch, we’d love to have you try it out and give us feedback.
I would love to try it out. Ihave some experience in this matter too. But there is one question, I needed to ask, “Can the API break a document which I have no intentions to change?” In other words, if I am using the API only on Doc1, does that can alter the behavior of Doc2?
Most likely the API will have a way for you to programmatically select the document to work on.
As long as the code you write to access the API selects the right doc, no other documents will be affected. If somehow your code inadvertently selects the wrong doc, then that’s another story.
@Richard_Kaplan is correct. Right now, our API only provides write access to table rows within a specific doc. So, you could potentially break an individual doc by writing bad data to it (i.e., data that doesn’t match up with what some of your formulas might expect), but it won’t affect other docs.
That being said, changes made via the API work the same way as if you had made them manually - you can always go into version history for a doc and see prior versions.
With breaking the doc, do you mean making the doc completely broken or just break some part of the doc? I guess you mean the latter. Given the latter I guess you can always go in and fix the doc manually or use revision control go back to a working state.
Perhaps “breaking” was too strong a word. I just meant the latter - doing something like writing text to a column with all numbers, causing any formulas that expect numbers in that column to now error, for instance. Nothing you wouldn’t also be able to do in your browser on coda.io too.
In case you haven’t gotten a chance to check out your emails, we’ve officially moved into public beta with the API! Huge thanks to everyone who has given us feedback along the way. Some of the assets that I wanted to share out:
Having support for more powerful queries is on our list - that’s an interesting take on using the formula language, though that will likely be infeasible in the short term for technical reasons (the short of it is that running a Coda formula requires us to load the whole doc each time, and that would make API queries slow).
As for referencing columns, you can reference them by name in all places you can reference them by ID. For querying tables, for instance, see the docs here.
I am Patrick and I am so impressed by the template you and @preeyanka built. It really gives me a thunderstrike on how to make further use about Coda.
I am playing around on your template and I have a question to ask about the “Syncing the Google Calendar”.
May I know if I have several calendars want to sync to the table in Coda, how can I do that and the best way you recommend?
If you have several calendars you’d like to sync, you have a number of options. The easiest way would be to just create multiple versions of the script, each with different parameters, and then you could sync calendars to their own individual tables.
What I’d personally likely find more useful would be to combine events from multiple calendars into one table, using a new column called “Calendar name”. That way you could take advantage of grouping as needed or work with all your events at once. To do this, you’d have to tweak the script to call getCalendarData() once for each of your calendars, and then combine all the events into one array. You’ll also want to add that new column for the calendar name so you could differentiate them.
Something like this (untested):
GOOGLE_CALENDAR_NAMES = ['calendar1@gmail.com', 'calendar2@gmail.com'];
// ...
// Get calendar data from Google Calendar.
var events = [];
for each (var calName in GOOGLE_CALENDAR_NAMES) {
var newEvents = getCalendarData(calName, syncRange).map(function(event) {
return Object.assign(event, {calName: calName});
});
events = events.concat(newEvents);
}
// Construct rows to upsert into Coda.
var rows = [];
for each (var event in events) {
var guestEmails = [];
var guestNames = [];
for each (var guest in event.getGuestList()) {
guestEmails.push(guest.getEmail());
guestNames.push(guest.getName() || guest.getEmail());
}
// This part is pretty slow - each of the Event functions like `getStartTime()` appears
// to make a new call to Google Calendar, and there are no batch get functions.
var row = {
cells: [
{column: 'ID', value: event.getId()},
{column: 'Start Time', value: event.getStartTime()},
{column: 'Calendar', value: event.calName},
// ...
Hi @oleg
Thanks for your swiftly response on my enquiries and thanks for the elegant example provided.
Just one more question.
I encountered error when running the script and seems GAS does not support “Object.assign(event, {calName: calName}” (Details please find the screen cap below).
I tried to search through google and hope to find a solution but failed.
May I seek your advice again so I can taste the success of building my first draft in Coda?
Deeply thanks !
You could try this polyfill, or alternatively rewrite to return {calName: calName, event: event} on line 34 and read the calendar name/event details from there later (i.e., change event.getId() to event.event.getId(), etc. and keep event.calName).
