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…
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?
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.
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.
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.