I’m developing a pack, and in this case, the API (it’s Wave Accounting) returns a businessId to which the user has granted permissions. A user might have multiple “businesses”, and the OAuth flow asks the user to choose one.
Then, most other API calls need this businessId to be sent along.
Is there a way for the pack to store this businessId somewhere, so that it can be used in other operations without the need to create an explicit user-visible parameter?
This is similar in some way to the Jira sample where a postSetup is used to determine the endpoint url, except in my case, the url is the same for all businesses, but each request requires the businessId as part of the POST data.
My current solution is to always add the businessId as a parameter with autocomplete, where it pulls the value from the API, but this seems sub-optimal.
The URL expires after 15 minutes by default, but you may pass a custom expiry, however Coda reserves the right to ignore long expirations.
In my case, it needs to be as long-lived as the connected account.
The closest I found to what I’d need is the account-specific endpoint. A hacky approach would be (I think) to append a businessId=ABC123 query param to the endpoint, then extract that value from context on each request.
@Leandro_Zubrezki and I experienced similar issues with our QuickBooks Packs. We’ve had to resort to users supplying the companyId in formulas for the time being, but depending on when/how that companyId is returned, you may have better luck than we did.
Some oAuth API responses can be captured, I think mostly user-specific endpoint yeah. Perhaps @Eric_Koleda can weigh in based on the specific API spec here.
Hi @Dan_Guberman - Unfortunately extracting values from the OAuth token response isn’t something we support today, but we have had a few requests and it’s something we’re tracking. The two workarounds I know of have already been mentioned: adding a parameter to each formula or adding query parameters to the endpoint URL.
Hi @Eric_Koleda … Just to clarify, in my case, it’s not so much about extracting values from the OAuth token - yes, this value is part of the response, but I can also retrieve it later - and more about storing that bit of custom data per signed-in user account. A user-specific endpoint is one such bit of data, but it’s too restrictive in that it needs to be a URL.
The benefit is on the pack’s user side - there’s no need to provide that data as an additional parameter on every table they add or formula they use.
Ya, that makes sense. For some APIs (like Quickbooks mentioned above) the OAuth token response is the only place where the data is returned, so it’s more critical that it be extracted from it. While I see the use case for storing arbitrary values along with the user, that’s something we’d probably have to do more carefully to ensure people aren’t stashing too much there, are using it as a cache, etc.
That makes sense to restrict it in some way. But it might be worth it to consider it more broadly, as it could allow for account-level config options in the UI.
Thanks!
I have other use cases for pack-account-level preferences too (of various types - “which account number” stuff like this, but also things like Boolean preferences or select-list options)