Get the number of records in a table via API

[Evgeny_Bylym]

Hi!

How to determine the number of records / entries in a table via API using curl / php / pyton?

Imagine a table with 12304 entries. Our current stumbling block is the API limit: we can only get 100 entries at a time via the API using PHP. In this regard, we have to make a lot of requests page by page. Then count the number of pages and multiply them by 100. Is there a more elegant way?

Thank you!

[Bill_French]

Justin_Barrett:

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.

LOL. Messy? Indeed!!! But that’s Airtable’s middle name (Air-Messy-Table).

The question you must ask -

Is it better to pull down 40,000 items to count them or call (a) which calls (b)?

Evgeny_Bylym:

We get 100 records via API. Then 100 more and so on till the end.
Actual number of records helps us to track the % of sync that is done.

Polling-based synchronization strategies are really inefficient. They don’t scale and in Airtable’s case, they can dramatically impact end user’s performance. Have you considered an action-based event handler that keeps your data in sync?

[kuovonne]

Justin_Barrett:

that just feels messy, doesn’t it

I agree with Bill that it is messy but also a better method of getting a record count than the alternative presented.

Having to read all of the records in a table to get the total count is fairly common in database systems.

Airtable webhook automations are still also technically in Alpha, so new features might still get added. Although it isn’t clear if it will ever get out of alpha or if it is under active development or not.

It also wasn’t clear in the original post that the target needing the total was another Airtable base.

[Justin_Barrett]

kuovonne:

Having to read all of the records in a table to get the total count is fairly common in database systems.

I agree. I never disputed that. My comment about messiness was regarding the multi-tiered calling process (Item A calling Item B calling Item C) that was proposed. I still don’t see what’s wrong with reducing the number of calls from two to one by using some form of caching system.

Evgeny_Bylym:

We’ve decided to act in a less risky way:

1. Created a separate table named ‘Total’.
2. Added Link field to initial table. It links records with ‘Total’ table.
3. Added automation that runs when a record is created the initial table. It links all new records in the initial table with a single record in ‘Total’ table if triggered.
4. Created a Count field in a ‘Total’ table. It counts all linked entries.

While less risky, you’ll churn through your automation count quite quickly because the automation will be called for every new record. For example, if 100 new records are added at once, it will run 100 times, with each run linking one record. Your description makes it sound like it will only run once for each batch of new records, which is not the case.