Pretty sure you can’t just tack “api_key=xxxxxxx” on the end of the url. This returns an error for me (the same error you get). As per the API documentation you need to send a header value (using the -H flag) that contains the API key, e.g.:
curl "https://api.airtable.com/v0/appXXXXXXXXXXX/People?maxRecords=3&view=Grid%20view" \
-H "Authorization: Bearer YOUR_API_KEY"
Pretty sure you can’t just tack “api_key=xxxxxxx” on the end of the url. This returns an error for me (the same error you get). As per the API documentation you need to send a header value (using the -H flag) that contains the API key, e.g.:
curl "https://api.airtable.com/v0/appXXXXXXXXXXX/People?maxRecords=3&view=Grid%20view" \
-H "Authorization: Bearer YOUR_API_KEY"
@JonathanBowen Interestingly enough, for a GET request, it actually works within the URL for me, just as @David_Sturman outlined above! Even though Airtable doesn’t list it this way in the Airtable REST API documentation! Wow, I did not know this!
The API documentation for a base covers all of the tables in the base. Each table has its own section in the documentation.
Can you check for hidden spaces in the table name? It should not be possible to have a space at the beginning or end of a table name, but it still might have happened.
Are you sure that you have the correct BASE_ID? Could you possibly have the BASE_ID of a different, similar base that does not have a “Testers” table? Are you sure that you are using the value of the variable BASE_ID, and not the literal string “BASE_ID”?
As far as putting the API key as a url parameter, I have seen this before, and it isn’t clearly documented, but it works for GET requests. However, it is not as secure as including the api key in the header, so including the api key in the header is better.
The API documentation for a base covers all of the tables in the base. Each table has its own section in the documentation.
Can you check for hidden spaces in the table name? It should not be possible to have a space at the beginning or end of a table name, but it still might have happened.
Are you sure that you have the correct BASE_ID? Could you possibly have the BASE_ID of a different, similar base that does not have a “Testers” table? Are you sure that you are using the value of the variable BASE_ID, and not the literal string “BASE_ID”?
As far as putting the API key as a url parameter, I have seen this before, and it isn’t clearly documented, but it works for GET requests. However, it is not as secure as including the api key in the header, so including the api key in the header is better.
Okay. I APOLOGIZE TO EVERYBODY (except @ScottWorld who discovered something new 
). I was using the wrong base. I have a “Bug tracker” base in “My First Workspace” which was set up by default and a “Bug tracker” base in my project workspace. I was using the default one which doesn’t have the additional tables I added in the project workspace. @kuovonne, Thank you for your detailed response which clued me into looking to see why the documentation wasn’t showing me all the tables. It all works now that I am using the correct base and the documentation shows all the tables.
I agree that the -H version is more secure but I was just testing things out. I’ll use the -H in the final version.
Many thanks to rapid responses in this forum!!
