Fix "403 Forbidden" Error with Google Fusion Table REST API - json

Question

Background
I've created a Google Fusion Table, and set it to be public.
I am trying to access the data inside with Google's Rest API.
I'm using an API key rather than OEmbed.
The table ID is 17I-oLcU_9RNosUEtUBMS-k4MlBDCKNvipL00DHBI, so my query ends up as:
https://www.googleapis.com/fusiontables/v2/query?sql=SELECT * FROM 17I-oLcU_9RNosUEtUBMS-k4MlBDCKNvipL00DHBI&key=APIKEY
Problem
I'm getting back a 403 Forbidden error. I've tested my API key with some of the samples on Google's website, and getting back working data. But when I put in my table ID, I get this:
{
"error": {
"errors": [
{
"domain": "global",
"reason": "forbidden",
"message": "Forbidden"
}
],
"code": 403,
"message": "Forbidden"
}
}
Question:
Is there something else I need to do?

Answer 1

The answer isn't well documented in Google's official documentation, but it turns out that there is another setting buried further down than Sharing Settings.
Go to:
File -> About this table
That will pop up an overlay. Click on the "Edit table information" link.
This will take you to a new page. From there, select the checkbox that says Allow Downloads.
Once I changed that, my error instantly disappeared.

Answer 2

I was creating and deleting tables through the api with an authorized service account. After doing bulk deletes http forbidden errors started returning. I added a retry to my delete function and spammed it a few more times. At which point the deletes completely failed.
After reading this post I used the flag to update the "isExportable" property of the existing tables. Only a few of the tables updated with each pass. The remaining update calls returned http forbidden errors.
Those that did update I could delete through the api. I'm now stuck with 10 tables that will not delete or update. I've created new tables with the "isExportable" set to "true" and they always delete fine.
It seems there is an issue with how "isExportable" is handled within fusion tables.
After 24 hours I checked back and the tables that were hung had been deleted. It would appear that a background process eventually took care of the deletes.
I hope this helps someone else.