Launched: New ways to integrate your toolstack into Coda

:wave:t5: everyone,

As Gleb shared above, we’ve now made Coda page embeds editable! This is the first step in the path toward granular content sharing that I outlined in my previous response. We hope this will provide a more seamless experience for you all and broaden the range of use cases you can leverage full-page embeds for.

As mentioned, the next step in Coda’s content sharing evolution will be to allow secure embedding of a single page in such a way that no other parts of the embedded doc are accessible. We’ll continue to reference your feedback and keep you in the loop as this takes shape — many thanks as always for your insights!


Hi @Ayuba_Audu ,

First of all, thank you for the clear communication about this topic here and elsewhere. Your efforts have not gone unnoticed :pray:.

I think the following step will be the crux of the problem - probably quite a technical feat to pull off:

allow secure embedding of a single page in such a way that no other parts of the embedded doc are accessible

What I hope this means:

  • Formulas created in SourceDoc/SharedPage continue to be executed in the ‘namespace’ of SourceDoc even when run from TargetDoc/SharedPaged, but with the User() formula returning the TargetDoc user.

  • The above extends to filtering formulas, so that I can prepare a filtered view in SourceDoc/SharedPage that returns different rows for different users, and have peace of mind that only the resulting rows will be accessible in TargetDoc, even to the clever users who know how to dig into Chrome’s developer tools and browse the page’s source.

  • Formulas in TargetDoc/SomeOtherPage can still reference objects in TargetDoc/SharedPage, but only its loaded content.

Can you tell us, without making promises, whether this is your general direction of travel?

Honestly, if you guys can pull this off then I will be one overjoyed customer. I’m no engineer, but I guess that getting it done would almost certainly involve switching to a model where calculations of the shared page are run on your servers instead of the browser…

To help get this over the line, here are some compromises I would be happy to make in TargetDoc/SharedPage:

  • It’s ok if it inherits locking settings from SourceDoc and these can’t be changed
  • It’s ok if I can only Use buttons, change table values, add/delete rows. No need to Edit page text, and no need to be able to write any new formulas.
  • It’s ok if new @ mentions only reference the SourceDoc namespace.

Happy to discuss this separately if this is not the right venue for this level of detail.


Appreciate the kind words and your detailed feedback — including compromises, @Nad! :pray:t5:

I can say that is the general direction. While there are more considerations, you’ve captured some of the concerns we’d want to address.


I am very excited about the editable page embeds and the upcoming sharing of single pages without access to the other parts of the embedded doc.

Does this mean that we will have the ability to embed pages into another doc and let users interact with them without granting them access to the original doc?

We have created a central repository for all of our information but would like an easy way to create team-specific documents that give users access to interact with the information that they need without giving them access to the full repository.


We’re excited as well, @Tracy_Horner!

Yes, they’ll have access to only the page you’re embedding and not the entire doc you’re embedding from.

In this case, one pattern we’ve seen from customers which might help short term is to create the team specific information in the team hubs / docs, then embed into the central repository. This way you don’t need to give access to the central repository, while still having a central place for all the content.

1 Like

hi @Tracy_Horner ,

I was as curious as you and tested it. Permissions need to be equal on two sides to get access to the embedded doc. The most confusing is when you embed a doc and people start to aks for permission to the source doc, but that you cannot give. In the below ‘see’ means see the content of the page, the page is visible in the doc.

as @Ayuba_Audu suggested, there are work arounds, but I’d rather avoid them. I assume Coda will solve this issue by the end of the summer, so I wait for that.

Cheers, Christiaan


This is great. I’ve hit a wall around needing editing of a table / page without being signed in. I hope this is part of your technical planning and I am sure it is as it is mentioned throughout the community.

1 Like

Hello @Gleb_Posobin , @coda_hq,

I have been doing some testing with embeds and although my main concern is the necessity to share both the original and the document with the embeds, this is a nice step forwards and certainly serves some use cases.

I have run into 2 things that might need to your attention while developing the next steps, I am writing this post to share them with you. This is about the doc with the embedded page(s).

  1. I have an embedded page with a table with a related column (to a person table). Upon hoovering over the person objects, I can expand the object and open a modal to these objects (persons in my case). So far so good, but at the top of the modal there is a link to the person table - and this table is not part of this specific doc. Upon clicking on the table link, the original document is opened and the table is exposed. Even though I am aware of the fact that the user has access to both the original doc and the doc with the embeds, I made the doc with the embeds to separate things and to nog have users (accidently) end up in the main doc.
    I hope this can be addressed.

  2. we have had issues with using some docs on Apple mobile phones, including the newest ones: the docs crash immediately or within seconds of opening. This is while using chrome, safari or the app. It seems to only happen with seriously big docs. I had the hope that with embedding only a few pages, this problem would be solved, but is it not: I am under the impression that the full (original) doc is loaded even though only a few pages are embedded. On Android we don’t have this problem, perhaps it will solve itself with a future ios update, but if Coda can prevent downloading the entire doc it would probably improve things too.

Thanks for your attention,
Greetings, Joost


Hey bill,

I’m just reading this massive thread but I quickly came up with something that could work reading into your problem?

(1) Coda has an API you can call to get your data from within tables inside of your doc
(2) You can structure your data in whatever way you want… as long as you know how the data looks like
(3) Store all the data in a data warehouse. Aggregate it with other data sources if you want
(4) You can run aggregate functions (Chatgpt, NLP) on your data warehouse

Would this be a solution to what you’re looking for? Albeit you’d have to natively build this xD

:wave:t5: everyone,

We have 2 more improvements to full-page embeds of Coda pages to share — clearer indications of locked page embeds and additional functionality on mobile.

You may notice that page embeds of locked Coda pages now closely reflect the locked experience of the source doc and indicate when an action isn’t possible due to the doc or page being locked. We hope this makes the process of viewing and editing these embeds more seamless.

Additionally, we have now added support for editing Coda page embeds on the mobile app, with an experience optimized for mobile.

Many thanks for all your thoughts and feedback as we continue making updates — we sincerely do appreciate it!


Thank you for the update. Could you let us know what the thinking is on allowing people who are not signed in to edit or interact with published docs? Thanks.

1 Like

:wave:t5: Hi everyone,

Many thanks again for your feedback and support as we continue to work towards sub-doc sharing in Coda.

As you may have seen, we introduced sync pages and the ability to add pages with their subpages to any doc as part of Coda 4.0 today.

To keep you all updated on our progress, I wrote an update on our content sharing roadmap here.

Give it a read and let us know what you think!


Thanks for the information. Step 4 on your roadmap is what I am waiting for. Do you have an estimated time for its completion? weeks, months, years?

1 Like

You’re welcome, @Jennifer_Biggs!

While we don’t have an estimate to share at this time as we’re gearing up for step 3 right now. please do watch for updates, especially as we get through step 3, thank you!

1 Like

Why Google Sheets and not Coda tables?

More or less?
It can be useful to consult with some linguists.

I’d schedule at least one public talk about this.
On what day would you talk publicly or privately about this?

:wave:t5: all,

Happy 2024 and many thanks for your continued feedback! :tada:

Our team has released an update today, which you can read about here.


@Ayuba_Audu , this is great news regarding embedding whole docs from coda.

But for full-page-embeds from other sources we still need a way to define the URL via a FORMULA!

We have so many use-cases where the URL of the embedded content is based on the user’s data held in their Coda tables.

But right now, the URL must be manually entered by the doc maker in every case!



An interesting finding I’ve discovered… If I use the direct link to a page in a doc that has edit access for anyone with the link and I append “viewMode=Edit” to the end, the embed works in the custom domain public site, as long as I’ve previously logged into Coda.

However, if I’m not logged in, I’m just presented with a “Coda refused to connect” error, where I feel it should just prompt for login?

This would largely solve my problems, I would just need to architect things into separate docs for editable content vs non editable content.

You can see it my example here: Embed Test · Forza Hub (

Also, another note… if you embed a published document link, the page is broken on the public custom domain site. it seems to only show the page header, even if its disabled. I don’t feel this is correct behaviour either. Surely if you can get to a published doc without logging in, it should work via embed?

1 Like