How do I programatically get a base's record limit?

[Eugene_Kim]

My Custom app syncs data from a 3rd party into a user’s Airtable base. Previously the app made an assumption that the user was at least using a Pro plan since apps were only allowed on Pro and Enterprise plans so I assumed I could sync up to 50,000 records.

Now that any plan can have an app, I need to detect the record limit for the base. Is there a way that I can do this?

Thank you

[kuovonne]

Currently there is no clear way for a custom app to determine the record limit for its base. One workaround is to use checkPermissionsForCreateField to see if you can create a checkbox field with a color or icon that is only available to pro plans. Of course this only works if the user has creator permissions, and it doesn’t tell you if the user might have a plus plan.

Custom apps can currently get the Workspace ID of the workspace, but no other details of the workspace. Hopefully this is a first step to eventually exposing more detail about the workspace that are reasonable to show to the base, such as the record and attachment limits.

[Bill_French]

Eugene_Kim:

Now that any plan can have an app, I need to detect the record limit for the base.

Crazy stupid idea. Create a table and fill it with 1201 records. If it fails, you have a 1200 record limit.

[kuovonne]

Bill.French:

Create a table and fill it with 1201 records. If it fails, you have a 1200 record limit.

I doubt this will work. The record limits are soft limits. Thus, creating the 1201th record will not fail, even if the official record is reached. Plus, the official limit is for the entire base, not just a single table, and the app has no control over other processes that might be creating and deleting records at the same time.

This also can impact other users who might be confused by new records being created and deleted. It will also clutter up the trash with the deleted records, making it harder for someone to find a specific item that needs to be restored from the trash.

[Bill_French]

kuovonne:

the official limit is for the entire base, not just a single table

Who cares - the objective is simple; is it a limited account or not. You needn’t be precise with this approach; just find the boundary as quickly and ugly as it may require, then delete any trace that you did this to learn the account’s boundary.

kuovonne:

I doubt this will work.

I doubt you are wrong. :winking_face: However, it might be worth a try.

kuovonne:

This also can impact other users who might be confused by new records being created and deleted.

I assumed one would do this inconspicuously and delete all evidence of the test. But, still - stupid crazy.

[kuovonne]

Bill.French:

delete all evidence of the test.

The custom app can delete the records created, but not remove those deleted records from the trash. Thus, it is impossible to delete all evidence of the test. Under normal circumstances, the records in the trash won’t be a big deal. But if someone needs to get something from the trash, and the trash is filled with all those deleted records, it will just add extra stress on someone who is already stressed due to needing to restore something from the trash.

If the user won’t have creator permissions, why not have a setting in the app where the user tells you how many records to sync? That way it is up to the user to decide if he wants to use certain logic to limit the number of records. You can also put a try/catch around the record creation code and if the create records fails, tell the user at runtime.

[Eugene_Kim]

Thanks for this! I like that I can definitively tell whether or not I’m dealing with a Pro plan with this idea. Shame that there isn’t a differentiator like this for the Plus plan. To start I think I might just have the user tell me what plan they have and if the sync doesn’t work b/c they didn’t choose the right plan then that’s on them.

[Eugene_Kim]

This would differentiate between all plans which is nice but I don’t think I’ll have my users sit down and wait while I create potentially over 50,000 records :grinning_face_with_sweat:

[Bill_French]

Eugene_Kim:

I don’t think I’ll have my users sit down and wait while I create potentially over 50,000 records :grinning_face_with_sweat:

That wasn’t the premise - create just 1201 and if it was rigid about that ceiling, you should see an error. But - still a bad idea.

One other crazy one - the free plan doesn’t support color in option lists. If you could create an arbitrary temporary select field and then attempt to assign options with color, the script should fail on the free plan and run on the pro plan.

[kuovonne]

Bill.French:

One other crazy one - the free plan doesn’t support color in option lists. If you could create an arbitrary temporary select field and then attempt to assign options with color, the script should fail on the free plan and run on the pro plan.

This is basically what I suggested in my first post in this thread, except that I suggested a checkbox field, and I suggested that you just check for the permission without actually creating the field. However, as I also mentioned, this technique requires that the current user have creator privileges.