I encountered a confusing error message in the Airtable Web API tonight that threw me off for a little bit.
This sort of situation will mostly be resolved when Airtable fully switches over to Personal Access Tokens. But for now, most 3rd-party apps (like Make and Zapier) are still connecting to Airtable’s API via Airtable user accounts.
So tonight, I was trying to create a new record via a user’s API Key in a table where the user actually did have permissions to “create records”.
However, what I didn’t realize is that this user didn’t have permission to edit a SPECIFIC FIELD that we needed to include in their POST request.
As a result of this discrepancy between table creation permissions & field editing permissions, the API returned an error message that said:
The confusing thing about this error message is that it says that they don’t have permission to create an entire row. It confused me because when I went back into the base to investigate that table, they actually DID have permission to create records in the table!
I didn’t realize that the problem was that they don’t have permission to edit a specific field that we included in the POST request.
It would be amazing if Airtable’s error message was more clear about what the real problem was. Perhaps the error message could give the Field ID that caused the problem, or even better, just give a generic error message that they couldn’t create a row because they included a field that they don’t have editing permissions for.
Anyways, perhaps this will help someone in the future who encounters this same stumbling block!
I believe that Scripting Extension has a similar error message if the person running the script does not have edit permissions for one of the fields being populated when the script creates the record.
I don’t think that Personal Access Tokens will resolve this issue.
I think that personal access tokens will resolve this because as far as I can tell, personal access tokens can either write to “all fields” or “no fields”, but there is no field-level granularity involved.
However, with user API keys, that particular user might be locked off from certain fields.
I think that personal access tokens will not be able to have more privileges than the user actually has. So if a user has edit access to some fields, but not others, the personal access token for that user will have the same limitations.
The issue also applies when manually duplicating a record where someone lacks permissions to edit a particular field. I believe it also applies when creating a new record in a grouped grid view when the user does not have edit permissions for the grouped field.
Plus, this issue applies to scripting extension (and probably custom extensions) as well. Custom extensions actually has the option of checking if a user can create a record where the extension can submit field values to see if the user has permissions to create the record. This supports the idea that permissions to create records is tied to field level permissions across the product.
Oh, wow, that’s very interesting. I was under the exact opposite impression — that personal access token permissions were completely separate from the account-level permissions.
I need to test this out ASAP!
I’m extremely tempted to test this out right this moment, but it’s midnight here and I’m so exhausted, and I need to go to bed… if I go down this rabbit hole right now, I know that I won’t be in bed for at least another 45 minutes. Lol.
This is exactly how it works. The two security policies (user permissions + PAT token permissions) are intersected and then applied.
This means if a PAT is issued for a “Base A”, and then the user loses access to “Base A”, the PAT will not be able to access Base A, because both the PAT and user need access to the resource.
And thank you sooo much for the clarification on this topic!
I’m so glad to fully understand this now, which also means that the confusing API error message might have confused me with personal access tokens as well!
But not anymore — I fully understand it now. Thanks to you and @Kuovonne for your help!
