I am rather a beginner here, sorry if my question is stupid.
I explain my need: refreshing every X seconds something in an user’s Coda page based on the results of an API that I control.
I have two options:
My API should ask to the user where he wants to put data (tableId, columnId mapping, etc)
Or the user is doing this mapping on Coda’s side, and my Pack would do frequent requests to my API., typically every X seconds as I need a near real-time stuff.
Main disadvantages of the first solution
More coding on my API.
Implies that my API has access to the Page of the user, which is not ideal for confidentiality.
Main disadvantages of the second solution
Clearly ugly. My pack would make REST request every X seconds. I wonder if it’s authorized, and how it is managed.
Ideally, I would propose both solutions, but I still have some questions:
Is there any rate-limiting with the Fetch module of Coda? What is authorized? What is forbidden?
I didn’t see any docs on hooks. I would love this feature: implementing custom REST API endpoints into my pack, to avoid the ugly loop making request a remote endpoint.
Here are the webhooks docs (I think that’s what you’re describing with hooks).
I think the fastest a Pack can refresh a sync table on its own is hourly.
Out of curiosity, how often on average does the data change? Is it like, you’d want to check every 60 seconds because freshness is important, but 99% of those requests would have no change? Or is freshness important and data changes frequently?
Many thanks for the documentation on the hooks! I missed completely that!
It seems however that there is no added-value in terms of access right to the page, as it needs an API token with write-access to the doc.
I wonder why this design: this is not the POST request that is doing changes on the page, but what the user choose to do with this data. A token different from the API one would simplify a lot I guess:
API token: it will allow the external service to read/write modify your page directly.
Webhooks: it acts as a relay/proxy - you can receive data, but you needs to implement the related changes on your page
If I understand it correctly, webhooks use API tokens, so implementing a webhook = giving access to the page to the external service.
Use cases where data freshness is important: stock options / Finance, timers, Analytics dashboards (such as web traffic, sales, etc.), Monitoring dashboards (monitoring your servers…).
The token you create for a webhook automation is limited to only that automation by default. It’s not a generic read/write all to everything.
One big advantage of using a webhook vs simply adding rows via an API is that with the webhook you are more flexible with 1. how you pass your data (it doesn’t have to stick to the restv1/addrows schema but can be any JSON that you then parse), and 2. how you make row additions and changes, button presses etc within a single webhook trigger (i.e. your webhook can create three rows across three tables and then press a button to apply something else; with API requests you’d have to make those as separate api calls)
In your situation without reading too much into it, I’d use a webhook. That said, you still cannot flood Coda with new requests every second or so; there will be some rate limiting there too (I think it’s 20 requests for every 1 minute sliding window or something? and with automations it could be even more throttled because the server has to “launch” the doc in a headless recalc environment basically)