Can multiple sessions be open with the same account

[papparaziz]

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…

[EvanHahn]

We don’t have any code that prevents this sort of thing. Is their code giving back any errors from Airtable?

[papparaziz]

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?

[EvanHahn]

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.

[Cinxgler_Mariac]

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?

[EvanHahn]

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.)

[Bill_French]

@EvanHahn,

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.

[EvanHahn]

Bill.French:

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.

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.

[Bill_French]

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.

[TFP]

Nope, Airtable API completely ignores requests once the limit is reached.

EvanHahn:

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.

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:

1. A way to fetch multiple tables at once using a single API call. This will tremendously help not reach the limit.
2. A way to be notified about changes happening within a base (AKA webhooks).
   • We could build our own cache in front of Airtable API, but we can’t because there is no way to be notified (webhook). That might be untrue, maybe it’s possible through Automations now, but maybe it involves third-parties (Zapier, etc.) and their own limitations

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.