True, but that just feels messy, doesn’t it? Script A calls Webhook Automation B, which tallies the records and then calls Endpoint C with that value to do whatever is next. It feels like this awkward division of tasks between Script A and Endpoint C would make upkeep more of a pain. Also, if Endpoint C was another Airtable webhook-triggered automation, that eats up the webhook quota twice as fast.
All that aside, I’m curious to hear more from @Evgeny_Bylym re: what the record count is being used for. Is it just displayed in an interface of some kind, or does it have a greater purpose? Either way, perhaps that value could be cached in the target base and retrieved directly when needed. Along that line, the only option that comes to mind would be to have a timed automation in that base save the record count from the main table into a single record in another table. The script in question then retrieves that single record to get the count. It’s kinda messy in its own way—keeping a table with no other purpose than to store a single value, and the retrieved count may be off if it’s grabbed between automation runs—but it’s also simpler because the main script can both retrieve that value and do whatever needs to be done with it.