I am working on a Pack that uses a REST API where I am constantly sending an organization id that ends up being the same for every request, but I have to make it a parameter everywhere in order to send the API requests properly. What I would like to do is have the pack query the user once for this organization id, either during authorization or in the pack preferences, then apply that for all API calls under that pack account.
Is there a way to do this?
Hi @Skyler_Tolman1 - Welcome to the community, and happy to hear you are making a Pack! Unfortunately there isn’t a preferences system for Packs, and the only durable settings are those attached to the account created when the user signs in.
If the API you are connecting to only needs a simple token to connect, you can use the Custom authentication scheme to define multiple user inputs, which you can insert into the URL, headers, or body of your requests.
If the API requires OAuth2 then then you can add a SetEndpoint post-setup step which prompts the user to select an endpoint. This approach only works if there is an endpoint to list the available organizations however, since the user can’t enter the value directly. Also, if your organization ID is baked in the URL then this is fairly straightforward, but if it’s passed as a URL param then you’ll need to use some creative workarounds I can explain in more depth.
P.S. - A third and less user-friendly route is to store the organization ID in a named canvas control (text box, select list, etc) and then reference that control in all of your other formulas and tables. It’s easier then passing the value every time, but requires the user to setup their doc a certain way.
It is very unfortunate because this pattern exists pervasively for many solutions including, but not limited to APIs. I would really like to see an ENV() method in Packs that use the temporary blob storage in a useful persistent K/V store.
Another way (for Pack makers) to overcome this is to proxy the API interface with something like AutoCode or Deno which can then use locally set environment variables or even call out to the Coda API to get the quasi-static values the process may need. Lotta work to overcome a relatively simple requirement, though.
This is actually my current solution. but I am interested in your other option with the custom end point.
The authentication scheme I am using is the Basic authentication, where the token is passed as the password, so I’m not sure if I can effectively use the Custom auth scheme.
The organization id is passed as part of the URL.
@Eric_Koleda, thanks for the suggestion. I was able to add a manual endpoint in the authentication settings where the user can specify their organization, which is accessible via the context.endpoint variable for all my requests.