Another newbie question here! Please see the Dictionary Pack Code below for reference. Does the pack user get the key or does the pack maker provide the key in the code? If the latter, does the pack maker obtain the key from the API? It is my understanding that there could be freemium restrictions with some API’s. Is this code a good template for APIs that require keys?
I saw this post but it’s a bit over my head: Pass a user token into Pack via settings? - #3 by Eric_Koleda
Dictionary Pack Code:
// The Merriam-Webster API uses an API token, which should be included in
// request urls in a “key=” parameter, so we configure that here. When
// running coda auth examples/dictionary/pack.ts
you will be prompted
// to enter your API key to use when using coda execute
to exercise formulas
// in this pack. Users would be prompted to enter an API key when installing
// this pack in the Coda UI.
pack.setUserAuthentication({
type: coda.AuthenticationType.QueryParamToken,
paramName: “key”,
});
1 Like
Hi @Lynn_vK - In that particular example the user would have to obtain the key, which can tell since it uses setUserAuthentication()
. If instead it used setSystemAuthentication()
that would mean it’s got one key shared by everyone. You can read more about per-user vs system-wide authentication here.
Whether or not to require each user to get their own key vs using a single key that all users share is decision that Pack makers often have to make. From a usability point of view it’s much better to have a single key, especially if getting a key requires signing up for a developer account. This isn’t always possible or feasible however, with some common cases being:
- Each key only allows access to the data from the account that created it, so each user must bring their own key.
- Using the API costs money, and the Pack maker doesn’t want to pay the bill for all of their users.
- The API puts a rate limit on each API key, and all users sharing the same key would put it over that limit.
Let me know if that answers your question.
2 Likes
Hi Eric,
I see that Coda has a system-wide code snippet for the RapidAPI auth (below). If the API exists on Rapid API, is this the code to use after obtaining the key on Rapid API? (I know that one has to be careful with limits for freemium accounts.) Is there any other code required related to the authorization or is this it, and then one would continue with defining the schema, formula, execution, etc. thereafter?
Custom header¶
Authentication that passes a long-lived token in a custom header. This sample connects to RapidAPI.
import * as coda from "@codahq/packs-sdk";
export const pack = coda.newPack();
// System-wide authentication to RapidAPI, using an API key in a custom header.
// See https://docs.rapidapi.com/docs/keys#how-to-find-your-api-key.
pack.setSystemAuthentication({
type: coda.AuthenticationType.CustomHeaderToken,
headerName: "X-RapidAPI-Key",
});
// Allow the pack to make requests to RapidAPI.
pack.addNetworkDomain("rapidapi.com");
1 Like
Yep this would work. Because it’s system authentication, you will provide a single API key from your own RapidAPI account. After you’ve coded the pack to require system authentication (e.g. the code snippet you shared), you input your actual API key here:
And then now, when you make any requests with context.fetcher.fetch(...
, they will carry this API key info along with them and will automatically authenticate (so in your code you can just focus on the basics like what URL are you hitting, and what body
do you need to include in the request, if any - but no auth stuff).
2 Likes
Thank you Nick. I’m enjoying the challenge!