Coda API resolveBrowserLink not working as expected for table links

I am using the Coda API and trying to call the resolveBrowserLink endpoint in order to get metadata about a table.

When I make the request (with valid Bearer token) with query param url set to the link to the table I copied from a doc using the three dot menu on a table, e.g., I get back a response for the page rather than the table, e.g.:

    "type": "apiLink",
    "href": "",
    "browserLink": "",
    "resource": {
        "type": "page",
        "id": "canvas-YjXM1a22ql",
        "href": "",
        "name": "Untitled"

Is this some sort of URL encoding issue?

Hi Louca! Make sure you’ve fully clicked into the table or table header, you should see a url that ends with #Table_something. And then yeah, make sure you encode that url before including it in the resolveBrowserLink url.

Make sure you’ve fully clicked into the table or table header

Could you illustrate how to do this?

I have clicked the title of the table, then clicked the three dot menu that appears in the left margin, then clicked copy link, and I get this link

When you say #Table_something does it literally include the word “Table” in there?

Sorry about that. The easiest thing to do is probably to click into the table name. You’ll know you’ve clicked into the right place if you see the table name right after the hash symbol.

Thanks, so it seems that when doing your approach and then selecting the url from the browser url bar, the API works as expected. But when using the three dot menu for the table and selecting the menu option to “Copy link”, it gives a different link which does not work.

Edit: workaround seems to be changing the _l to _t, which I guess specifies that the object is a table and not an arbitrary thing (paragraph? link?). E.g.:




_luXXX is a line stub
_tuXXX is a table/view stub
They are the same for the lines that host tables, so simply replacing _lu with _tu will actually work.

The stub is actually the last 3 characters of the full 10-character ID.

There’s one more thing: the endpoint wrongly returns an incorrect href for views: it has /views/table-xxx... in its URL, but it has to always be /tables/table-xxx... regardless if it’s a table or a view.

(Although if you haven’t noticed it, maybe it’s fixed already)