We can get the DOC ID with a formula URL() and parsing the URL.
How can we get the Table ID directly in a formula or separately by converting/parsing the URL()?
Examples:
Thanks
David
If you’re using the API, you could use resolveBrowserLink to resolve the full table ID from the URL.
If you’re in the doc with the given table, we don’t officially expose a way of getting this ID. What you could do for now (which is a hack and using a hidden formula / mechanism that may eventually break) is write a formula like:
ParseJson(_MERGE([Table 1]), "#/objectId")
Where the parameter is your table name. (This works because _MERGE tricks our formula engine into treating the table reference as an object, and you can inspect it by writing ToText(_MERGE(...))). I’m sure @Paul_Danyliuk posted about this somewhere in the community already.
Also, without the hidden formula, you can get table ID / row ID like:
thisRow + ""
You can then split it by / and take the first/last part.
Thanks @oleg @Paul_Danyliuk 
nth(split((thisRow + “”),"/"),1)
@David_Greenwood by the way, could you share your use case for this? I’m just wondering if this is something we can better support in the future with a set of formulas or a Pack (e.g., a Pack that gives you API-related metadata for an object you pass in).
Note that the thisRow + " solution is also a hack and might stop working if we revisit how the + operator works in the future.
@oleg Sorry to hear this solution is a hack that we cannot rely on 
It seems to be a critical requirement to have durable formula access to DocID and TableID given they are essential requirements of the API. Are there any plans to resolve this soon?
I will post separately some Suggestions about Packs and the API with relevant use cases.
Note that we have a couple solutions for working with these IDs:
Could you provide some use cases for why you’d need formulaic access to these IDs? That would be helpful for us and most likely we’d implement this in the form of a special Coda Developer Pack.
@oleg We are using the Table ID becuse in the API “Names are discouraged because they’re easily prone to being changed by users. If you’re using a name, be sure to URI-encode it.”
We are looking for a suitable platform like Coda to implement/extend some app/widget based solutions.
At this stage we are doing some logical and functional prototyping to explore what’s possible.
Use Case: An external app stores data in a Coda Table.
There are some obvious limitations and risks with this approach:
API performance, reliability and capability
It requires clumsy user action and can be broken
Conflicting changes when Table and App are udated simultaneously by different users (Option: Upgrade to Team Page Locking to avoid this and Cross-doc to replicate in another location).
Thanks for your interest! Any update on API 2.0, relevant roadmap items, feedback or ideas you have would be greatly appreciated 
Gotcha, thanks for explaining. One thing to note is that if you make a copy of a doc, IDs of object within the doc will remain the same. So you could potentially just hard-code the table ID there and it should work in copies of your doc.
We only recently launched v1 of our API this summer (Coda API v1 Launched) and don’t have any plans to work on a newer API. We could support updating columns in the current API without breaking changes, but there has been little demand for it so we’ve been prioritizing other non-API work.
Thanks for the advice on objects and the Table ID staying the same but the Doc ID changes and we still need that to reference the Table data using the API.
It would be great to get API support for creating and naming columns. What about the same for tables, is that viable within the current API without breaking anything?
Yeah, those would be additions to the current API and could be safely introduced. No planned work around that at the moment - I think your approach of copying a “template doc” is the best solution for now. As for extracting the doc ID, you could write a formula like this for now:
thisDocument.Url().Split('_').Slice(2).Join('')
Ok thanks, that seems to be the only semi-viable approach at the moment but I think too clumsy for users.
A more viable approach may be in developers being able to create D&D Templates mentioned in my post. Any ETA on that or possibility of getting one created?
Hey @oleg this related post Embed External App with selected file link and/or arguments is trying another approach. Your thoughts?
Custom D&D templates is something folks have brought up before but I can’t share any ETAs on that, though it’s something we’re looking into. I’ll do my best to answer your other questions on that post.
@David_Greenwood check n8n.io
In a Coda node you can have these as variables and extend automation and break down steps, I think it can be a good alternative if I get your case right.
Thanks Khalid, good to know about n8n. I will investigate further its value in solving the use case around linking specfic urls to a run-time embed path or arguments. Unfortunately, I have not seen any support in the Coda API or OTB functionality for it.
Hi @oleg 
Is there a possibility to reference a table via ID, like I want to know when was the last update on my various tables in Coda, instead of making for each a column table_1.modified.max(), table_2.modified.max() using a formula like table_id.modified.max()
Hope I explained it well enough 
Best
Thomas
Hi @thomas_raizedai, sounds like you’ve figured out a workable approach. Perhaps an alternative would be to look at the updatedAt timestamp on the whole doc, which you can get via the getDoc endpoint.