PAT instead of API key

[matthewjrogers]

PAT instead of API key

[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.

[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.