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

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.

Crazy stupid idea. 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.

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.

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

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

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.

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.

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:

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.

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.

Precisely; it is not predictable. I have a hunch that there’s something in the scripting environment that will fail under a free account. If you could find that one little glitch where Airtable has overlooked an incompatibility of scripts with free accounts. Oddly, we need something that doesn’t work to detect what would work. :winking_face:

Are you looking for something that will fail for an editor (versus a creator)?

If you are a creator and try to create a field with an icon or color that isn’t available to free accounts, that will fail, whether you are using scripting or a custom app. However, the original poster was asking about a custom app, not scripting. In a custom app you can check the permissions without having to actually attempt creating the field.

Another option would be to look for something that is available only to pro accounts, such as the existence of a field with a paid icon or color, or a large number of records, or a particular type of view. However this method isn’t very good either because they might not exist in a pro base because they were not needed in the base, or they might exist in a free base because they were created before the base was moved into a free workspace.

Really, I think that asking the user is the best option.

Isn’t that all that’s needed - an indication of failure determines the account level.

It’s not ideal because invariably, that will change and then you need to plan for an update process to be certain of what’s possible in the custom app, right?

I think we’re in the world where no solution will be ideal since Airtable doesn’t provide us this knowledge ahead of time.

Sadly, this is true. Airtable is not known for thinking carefully about how aftermarket developers of solutions will create workflows that are commerce-centric.