I did not see these APIs in the documentation. Does anybody know if these APIS exist? - createTable, createFieldInARecord, createView .
We don’t have those APIs right now. Can you share how you might use them to help inform our prioritization?
One example: fetching data from another API which returns json.
As of now we have to create the table and all the fields and only then the api data can be populated into Airtable.
With createTable and fields API - we can query the data and automatically create the Table and all the fields required. User only had to customize the field types if required.
@Kasra, I also have a use case that starts repeating itself - in case of a saas block (i.e. a product where each base is a customer) use the base as the backend db of the saas block (or at least store some of it’s base specific data in there) - I would make it so that those tables can be hidden or not editable by default (or at all) (i.e. block tables), so that users don’t change the schema of those tables, and break the block.
A similar concept can be found in the shopify api, with metafields that shopify apps can create for their own use and store their app specific data there.
I know you can use the GlobalConfig for this, but then I loose all of the advanced features that come with doing it with tables and the blocks api - and more importantly, you cannot access that data from outside the block - i.e. from the regular airtable api, by parts of your product that run outside the block.
I’ve also been poking around the documentation to see if it’s possible to configure a field in a table programmatically.
My use case is to sync data from a table in one base to a table in a separate base. I’m attempting to create a scripting block to do this.
The endpoints that would be extremely useful for this type of usecase are createFields or updateFields.
@Kasra – Am I understanding correctly that it is not currently possible to programmatically create/update fields in a table either via API call or via the scripting block interface?
I got almost the same Use Case but in addition to this I would programmatically customize the field types & type format if required.
The more I think about it, the more it makes sense to have block-specific tables, similar to app storage in mobile apps. The user can’t edit them (or, in v2, edit only specific fields in them, if block permits), or even view them??, but he can uninstall the block or clear the data in them. Blocks can use them via the blocks api and get all if it’s goodies or from the public airtable api.
Airtable can hugely benefit from it by tying them into the pricing model - block table records count against # of records in plan and the user can see how many records a block consumes.
Later on, airtable can provide blocks with an api to publish which tables they use, the purpose of each table, and how many records they use, and allow the user to clear data on a per table basis. For example, clear old log data, but keep config data, similar to deciding what to clear in the browser history.
@Kasra any plans for such a thing?