PAT instead of API key

[timothoms]

Airtable is phasing out API keys by next year, eventually making users migrate to Personal Access Tokens (PATs). Can the set_airtable_api_key() function be used with PATs? If not, will there be a new function for this? Thanks!

[matthewjrogers]

Hey there @timothoms -- thanks for bringing this to my attention!

I'm not sure if they use (or will use) PATs in the same manner as they currently use the API key. Right now, the API key stored by set_airtable_api_key() is passed to an Authorization header in the relevant GET/POST/PATCH/DELETE request. If PATs are going to be expected differently, I'll have to make some changes to keep set_airtable_api_key() compliant. I took a quick look at the API documentation and don't see anything yet.

When there's a clear path forward, I'll likely deprecate set_airtable_api_key() in favor of a new function. My guess is that the major functionality it will need is improved error handling, as it'd be easy to have permissions errors related to PAT scope the the current function might not surface in a helpful way.

[timothoms]

Great, thanks! Might be useful to keep set_airtable_api_key() until Airtable deprecates it in Jan 2024.

Does this documentation help?: https://airtable.com/developers/web/api/authentication

[matthewjrogers]

That's perfect, I hadn't seen that. That confirms that the tokens and api keys are used in the same way, so the set function will actually work as-is, though I think there should be a PAT-specific function for clarity

I'm thinking that the cadence for retiring set_airtable_api_key() would be 1) Add deprecation warnings to set_airtable_api_key() and release a new set_airtable_pat function 2) End of 2024, remove set_airtable_api_key

Since the PATs have scope limitations, it seems like it might be useful to have a means of storing more than one PAT and being able to select between them.

[timothoms]

That sounds great, and seems the right way to go. I will try out the set_airtable_api_key()with a new PAT. (And will report back if it doesn't work as expected.) Thanks.

[coreysparks]

@timothoms did you get this to work with a PAT? If so, could you share how you did it?

[timothoms]

@timothoms did you get this to work with a PAT? If so, could you share how you did it?

Yes, this worked as a drop-in replacement for me. I created a PAT with the scope "data.records:read" and then set it once with

set_airtable_api_key("MY_NEW_PAT_HERE", install = TRUE)

If you want to immediately use it, you need to

readRenviron("~/.Renviron")

Otherwise, restarting R should do it. You can check with

Sys.getenv("AIRTABLE_API_KEY")

[coreysparks]

Thanks! I'm getting an error, my setup looks like `test <- airtable( base = "app*****", table = c("Table Name") )

read_airtable(test,id_to_col = T ) ` The error is Error in read_airtable(test, id_to_col = T) : Unauthorized (HTTP 401). Failed to Fetch Airtable records.

[timothoms]

Thanks! I'm getting an error, my setup looks like `test <- airtable( base = "app*****", table = c("Table Name") )

read_airtable(test,id_to_col = T ) ` The error is Error in read_airtable(test, id_to_col = T) : Unauthorized (HTTP 401). Failed to Fetch Airtable records.

The R code looks correct to me, but there is an authorization issue. The error message indicates that the authentication token is invalid (see this). I'm guessing the problem is on the Airtable side, either the scope or access of the PAT is incorrect, or the user is not allowed the action, though the latter seems unlikely for just reading data.

[coreysparks]

I've asked someone else on my team and it may be because our airtable is behind Okta, thanks for your help!