When I make an API call using a Personal Access Token I have set up, it returns Error 401 Authentication Required - but if I change out the PAT to use the API Key, it works just fine.
Am I not able to use PAT's whilst I have a API Key enabled?
Solved
Authentication for Personal Access Tokens not working?
+3Best answer by keola
I'm so silly... the reason my PAT's were not working is because I was only using the Token ID - not the whole Token itself.
I went through the process of creating a new Token and immediately noticed my foolish error.
+20Hey @keola!
Did you confirm that the token that you've set up has been properly scoped for the operations that you're trying to do via the API?
Can you provide any additional details on what you're trying to do with the API? That will make it easier to confirm which scopes you need to add to your token.
That tends to be the primary culprit when I've been provisioning a new token for authenticating against the Web API.
+3Ben_Young1 wrote:
Hey @keola!
Did you confirm that the token that you've set up has been properly scoped for the operations that you're trying to do via the API?
Can you provide any additional details on what you're trying to do with the API? That will make it easier to confirm which scopes you need to add to your token.
That tends to be the primary culprit when I've been provisioning a new token for authenticating against the Web API.
Hey @Ben_Young1, yes - I have actually granted this PAT I am testing every scope. When I first create the tokens, I was getting the same error and I thought maybe I hadn't given enough scopes to the token, which is why I have now granted every scope to it.
+20keola wrote:
Hey @Ben_Young1, yes - I have actually granted this PAT I am testing every scope. When I first create the tokens, I was getting the same error and I thought maybe I hadn't given enough scopes to the token, which is why I have now granted every scope to it.
Can you provide a code snippet of how you're passing your HTTP request to the Airtable Web API?
If scope isn't the issue, then my next suspect falls to a syntax issue with how you're handling the headers object.
+3Ben_Young1 wrote:
Can you provide a code snippet of how you're passing your HTTP request to the Airtable Web API?
If scope isn't the issue, then my next suspect falls to a syntax issue with how you're handling the headers object.
I'm using the Authorization header with Bearer ###
+20keola wrote:
I'm using the Authorization header with Bearer ###
Could you provide a (scrubbed) snippet of your actual request?
Also, any additional information on what you're actually trying to do or which API endpoint(s) you're trying to interact with would also be a great help here.
Specifically, a snippet like this:
curl "https://api.airtable.com/v0/{myBaseId}/{myTableId}" \
-H "Authorization: Bearer {myToken}"Or if you're making this request in JS, something like this:
const AIRTABLE_TOKEN = "yourToken";
const requestUrl = "https://api.airtable.com/v0/";
const options = {
method: "GET",
headers: {
authorization: `Bearer ${AIRTABLE_TOKEN}`
}
};
await fetch(`${requestUrl}${baseId}/${tableId}`, options)
.then(request => request.json())
.then(data => console.log(data));Seeing how you're actually making the request is the key here.
+3Ben_Young1 wrote:
Could you provide a (scrubbed) snippet of your actual request?
Also, any additional information on what you're actually trying to do or which API endpoint(s) you're trying to interact with would also be a great help here.
Specifically, a snippet like this:
curl "https://api.airtable.com/v0/{myBaseId}/{myTableId}" \
-H "Authorization: Bearer {myToken}"Or if you're making this request in JS, something like this:
const AIRTABLE_TOKEN = "yourToken";
const requestUrl = "https://api.airtable.com/v0/";
const options = {
method: "GET",
headers: {
authorization: `Bearer ${AIRTABLE_TOKEN}`
}
};
await fetch(`${requestUrl}${baseId}/${tableId}`, options)
.then(request => request.json())
.then(data => console.log(data));Seeing how you're actually making the request is the key here.
I'm using Insomnia to test the call - the Body is set to No Body and the Auth is set to No Authentication (so I can pass it in the Header myself)
+27What are you using to make the API call? Are you using 100% your own code, or are you using a service? Some third party services could be set up to accept only API keys and not personal access tokens.
(This probably isn't the case, but I thought I'd throw the idea out there just in case.)
+3kuovonne wrote:
What are you using to make the API call? Are you using 100% your own code, or are you using a service? Some third party services could be set up to accept only API keys and not personal access tokens.
(This probably isn't the case, but I thought I'd throw the idea out there just in case.)
Hi @kuovonne; I'm using the program Insomnia to make the call at the moment, so no third party service.
+20keola wrote:
I'm using Insomnia to test the call - the Body is set to No Body and the Auth is set to No Authentication (so I can pass it in the Header myself)
Insomnia will handle the authentication headers for the request.
When I first started using Insomnia, I also ran into strange issues when I set my own authentication headers.
+3Ben_Young1 wrote:
Insomnia will handle the authentication headers for the request.
When I first started using Insomnia, I also ran into strange issues when I set my own authentication headers.
Yep - I have tried that way as well, still get the same error "Authentication Required"
+20There are no dependencies between the existence of access tokens and a previous user API key.
I have plenty of legacy API operations that are currently authenticated using my API key whilst simultaneously having been writing new connections with scoped access tokens.
This is proven in the fact that I'm able to make successful requests to the Web API as I posted in my previous screenshots.
+3Ben_Young1 wrote:
There are no dependencies between the existence of access tokens and a previous user API key.
I have plenty of legacy API operations that are currently authenticated using my API key whilst simultaneously having been writing new connections with scoped access tokens.
This is proven in the fact that I'm able to make successful requests to the Web API as I posted in my previous screenshots.
I didn't think there would be any dependencies between the two but this error has me totally stumped as to why my tokens would not be working - but the API key continues to work without issue.
+3I'm so silly... the reason my PAT's were not working is because I was only using the Token ID - not the whole Token itself.
I went through the process of creating a new Token and immediately noticed my foolish error.
+4keola wrote:
I'm so silly... the reason my PAT's were not working is because I was only using the Token ID - not the whole Token itself.
I went through the process of creating a new Token and immediately noticed my foolish error.
What do you mean by this? "I was only using the Token ID - not the whole token itself" do you mean not having the "pat" at the start of the token, or do you mean you were using the nickname of the token instead of the long string of text?
Edit: Now I see what you mean by Token ID. In your list of personal access tokens there is a Token ID field which is basically the first 14 characters of your pat.
Reply
Most helpful members this week
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.