Aug 01, 2019 10:48 AM
My engineers use my account’s API key to POST information into our Airtable base. Sometimes the data doesn’t always come through, the POST request appears successful but the data won’t make it to the table. This happens a lot. I wonder if it’s because my engineer uses my account’s API key and since I have an open session using the base with my account Airtable gets confused as to how the same person is editing the base in two different ways…
Aug 02, 2019 11:13 AM
We don’t have any code that prevents this sort of thing. Is their code giving back any errors from Airtable?
Aug 02, 2019 01:23 PM
Hi EvanHahn, thanks for responding! Not as far as I know, I have asked them to reply on this thread so maybe they can give you more clarity. However, maybe it’s a rate limit issue? Is the rate limit per database or per API key? Either way, my personal experience with rate limits is that even if you hit the rate limit the server will cache the pending requests and process them later, is this not the case with Airtable APIs?
Aug 02, 2019 01:37 PM
Our rate limit will start to give errors if you run up against them. I’d be curious to know what responses y’all are getting from the Airtable servers—that might help illuminate the issue.
Aug 05, 2019 02:57 PM
We are going to add some extra logging to try find out what is causing this.
In the meantime, I have a question, can you tell me if the rate limit is per API Key or per database?
Aug 06, 2019 07:23 AM
The rate limits for the public API endpoints are by base. (I admit we’re tweaking some of this so you may temporarily see higher rate limits than 5 requests per second per base, but please don’t rely on that—it should properly be 5 requests per second per base soon.)
Aug 12, 2019 08:38 AM
Ya know - one way to defend the Airtable servers from unintentional rate-limit abuse is to simply expose an event model internal to the API (and/or webhooks) that allow us to integrate external processes without polling for change.
Wouldn’t now be like the perfect time for Airtable to pave the way for developers to use your platform more efficiently while expanding the innovation possibilities?
I completely understand that saying this is easy and there are vast complexities involved, but it seems that without an event model, you will be playing whack-a-mole with this data accessibility issue for a long time. And all the while, innovation will be constrained.
Aug 14, 2019 11:38 AM
A webhook-style workflow is something that’s definitely on our radar. I don’t have any specifics I can share (though I’d like to tell all!!) but trust that this is something on our minds.
Aug 14, 2019 12:33 PM
Thanks for responding @EvanHahn!
If I could I’d click that thumbs up 200 times. I figured you guys were on that pathway - kind’a goes without saying in the API economy.
Holler if you need an old guy to test it.
Oct 27, 2020 04:27 AM
Nope, Airtable API completely ignores requests once the limit is reached.
This is really a must-have now, combined with the very low API limit (5 req/sec or similar), and the fact that only one table can be fetched at a time, it has become ridiculously easy to reach the said limit.
I’m fetching 19 tables to build my app, I had to build my own “latency” to make sure no more than 1 request is executed per second to take into account other API requests that could come from other systems. And it’s overall quite unreliable.
We need two things:
Both those missing features are becoming quite a pain to work with Airtable to build anything production-grade.
The fact that even Enterprise plans can’t get a higher limit than 5 req/sec is also very surprising.
Oct 27, 2020 05:14 AM
Possible, but every “webhook” and event context hast to be scripted, a tedious idea in a moderately complex app.