> ... if you build an api it's a lot easier to have your internal teams and consultants develop to that than directly. In that case, do actions on airtable tools such as interfaces and automations count as well?
They don't. Airtable [itself] is not built on the public API provided for customers. In fact, there is no common API for all customers; there is only a comment API endpoint that apparently distributes calls to bases in the context of each customer's Airtable instance. This is in stark contrast to other SaaS platforms that typically host API access for tenants in common. We know each API instance is tightly aligned with each customer's account because you can burden the entire customer instance, affecting your own user's performance without affecting other accounts.
> ... it creates a dilemma, and could explain the delay in making the numbers available.
Probably not the case.
> ... they have to have an ability to see where the API call came from
They don't, nor do they need to. Calls are calls and Airtable is not built on the public API. It's an indicator of load associated with your own account instance.
> ... and we got blocked because of calls from their own product, well, that would be mighty silly
This is not possible, but what is certainly silly is we pay for (x) service that runs inside of (y) container, which is designed to handle (z) load. Yet, Airtable has decided to expose a metric within the container and level of service we already paid for to create a new element that gates performance in a manner that affects the payment tier we choose. That seems silly. It's our paid instance and if we decide to burden it with 200,000 API calls and no end users or shared data, or any other activity, that should be the customer's prerogative.
I can understand if Airtable's position concerning these limitations was related to the common API endpoint gateway performance, but those types of services are usual and customary for a proxy, something that companies do very well, and load is generally not an issue. This is why I believe there should be no API limitations at all. If customers are okay with abusing their instance-based API, they should be free to do that. There are already adequate incentives to not abuse your service.
To be fair, there's one remaining out - Airtable could counter my argument by pointing out that they have a duty to protect customers from poor performance. After all, it does trigger support calls, and that is a cost Airtable must bear. Customers don't like performance issues. Gating API calls is likely the right knob for Airtable to turn if they've got data that shows people are abusing their instance-based APIs. You can't blame them for trying to keep you from killing your own performance because you chose a third-party portal product that has no regard for your API limitations.
I've tried to warn everyone for many years concerning the exuberant use of Make and Zapier and other platforms that incessantly poll every few minutes to see if anything's changed. My latest article is a flat-out indictment of the glue factories that make it very easy for you to engage in practices that only increase the likelihood you will see performance issues caused by API load.
Airtable has every right and, indeed, a duty to defend your service from our self-centered (sometimes lazy) interests in doing convenient things with external systems. Airtable has spent a lot of money building out the infrastructure to help us avoid using these external tools for every integration automation.
