Indeed, but you don’t. I’ve asked about an activity API for about five years. I’ve also been asking for a commenting API; no dice. I think @kuovonne is right - feel free to ask, but it’s likely a ways off, if ever.
But to that point, we cannot blame Airtable for this API shortfall; their focus is central to no/low-code and generally, users who need an events activity API fall into one or two classes of users:
- They are trying to use Airtable in a far more complicated fashion than typically no/low-code solution-builders use the product; or…
- They are trying to implement a solution that itself is poorly designed or at least a bad fit for Airtable.
Seeing your requirement and as it relates to #1, allowing users to run a lot of different scripts seems like a use case that is atypical.
I see this type of request all the time, and it’s a rational idea, especially for businesses whose transactions are subjected to compliance auditing:
I’m looking for a way to see the rowActivityInfoById for a record so I can audit what fields are being changed over a certain time period
However, I can’t recall seeing something like this; it’s a red flag for me.
We run so many field-altering scripts on our base …
One must ask - are you running scripts that alter values? Or actual are they modifying meta properties? “Field-altering” sometimes means you are changing the field type or the parameters of the field, not just the value stored in the field.
In any case, if users are manually running scripts that modify anything frequently, it begins to suggest you’re the #2 category, and you might want to rethink the approach.
Scripts, by and large, are intended to extend Airtable to meet a requirement that isn’t possible in any other way. If you have enough of these and they are a constant part of your data processing approach such that every user is firing off independent scripts, you may be creating a monster, and you now perceive an activity log as your only path to continued use of the solution. If that’s the case, perhaps you need a rethink on the solution as it pertains to your business domain.
There are parallels to this pattern in other databases. For example, SQL has stored procedures that are in constant use to overcome data issues and add value to existing data as it arrives. But unlike the scripts you describe, stored procedures are fired automatically and conditional and in a consistent manner. This leads me to ask - are your scripts bound into automations that run without user invocation?
