AMA Custom Blocks Contest Edition #1 - Getting Started with the Airtable Product Team (Live on Wednesday 6/10)

Hi @Matthew_Thomas!

Excited to hear that we’ve convinced you to give frontend development a try. Personally I find it easier to choose one example to structure a project skeleton around, and then drawing in aspects of other examples where helpful. Our product philosophy with the examples is to have each block focus on doing one thing well, in hopes to be able to draw on them as building blocks in your own project. I also find searching around for similar React projects to plan the skeleton a good way to begin too.

Without knowing which parts of React exactly that you’re struggling with (is it nesting components? Is it re-render? Is it how to flow data between components? Is it something to do with getting Airtable data?), I’d suggest the “Thinking in React” tutorial if you haven’t seen it already. It really helps take you through a process of building in a React-ey way. It also breaks down the process of building a React app into more manageable steps. It focuses first on getting components nested correctly. Then on putting state in the right components, then on passing data correctly. The example code uses React classes, but the techniques can be adapted to use hooks.

Hi @Eric_Ho

Absolutely. We’re actively building more example blocks and should be releasing a few more in the next week or two. Our product philosophy with the examples is to have each block focus on doing one thing well, in hopes to be able to draw on them as building blocks in your own project.

Are there any types of blocks that you’d be most interested in? Or is it more about demonstrating the SDK components that would be helpful?

1 Like

The installed blocks get updated when you run block release. Pushing to the master branch won’t automatically update installations.

As @Harshit_Juneja mentioned, if you want the same custom block across multiple bases, the best way to do that is to use the remotes feature for now. We’re exploring ways to make this more seamless in the future.

Hi @Michelle_Valentine - I have a business question that could help hone in on the types of blocks to build.

What types of teams are ‘power users’ of Airtable? (Either in terms of activity on Airtable or have the largest amount of users within a team using Airtable).

For example:

  • Do you see generally see many small businesses that use Airtable for one piece of their ‘stack’ (e.g. agencies that use it to track clients and billing).

  • Or for larger customers, do they use it to replace other services (e.g. using Airtable to track product dev tasks instead of doing it in JIRA).

  • On that note, do ‘power users’ benefit from integrating Airtable with other existing services (e.g. pulling in information from Salesforce to enrich a customer base in Airtable)

Any help in identifying the types of teams that fit your ideal customer could help narrow down the use case and approach.



Thank you, @Kasra. The picture is becoming a little more clear to me how $ block ... --remote handles this, and the questions in my head are kind of morphing as my understanding of it changes.

In particular, are you exploring ways to make keeping Custom Blocks updated a more seamless process for both creators and consumers of those blocks?

Technical question: do blocks allow for real-time updating of records within Airtable? Meaning, within my block, can I hit the Airtable API for the base that the block is installed in? I’m assuming yes since it’s just React within the block, but would I need the base user to put in their Airtable API token in the onboarding process within the block?

For a simple example if I wanted to get weather data every 10 minutes from an API and update a record within the base (and use the Block for another purpose like displaying the weather trends in near-real time), do you see any hiccups there? I’m not sure about the API rate limits.

I haven’t built on the Airtable API before so apologies if these questions are easily answered elsewhere.

I’m having some trouble getting some of the examples to install. Where do you suggest going for troubleshooting info on getting started? It can be hard to tell if my issue is an npm issue, a node issue, a react issue, or what. I haven’t worked in react before.

Thank you, I’m happy to hear it’s been a pleasant experience so far :raised_hands:

Can you give an overview of how setPathsAsync function works behind the scene and how much more performant it is for nested objects?

Both setAsync and setPathsAsync let you update nested values by passing in a path for the key. This is important if you want to avoid clobbering the other parts of the object if multiple users are writing to different parts of that object.

setPathsAsync is useful if you want to update multiple keys/paths in different parts of the tree in one shot. This is more performant than calling setAsync a bunch of times in rapid succession since setPathsAsync will end up making a single network call.

one of the other thing my Blocks app does is aggregating _changeCount values across records. I noticed that it doesn’t actually increment by 1 as it should. What’s happening here?

Any methods or variables that begin with an underscore (_) are private SDK internals and aren’t documented, so you shouldn’t rely on them in your code since their behavior may change at any point.

Is there a way to get data about specific record history?

There isn’t an API for getting this information at the moment, but I’ll note your +1 for it! Out of curiosity, what are you hoping to build with it?

1 Like

@Ashwin_Kumar – yes; Custom Blocks have a direct API with the base they are installed in; no need to use the REST API from within the Custom Block (unless you are wanting to interact with a completely separate base). You can simply call table.updateRecordAsync() to make updates to records within the base.


Hi @kuovonne!

We don’t have details to share on a developer plan yet, but rest assured that our intention is to make Airtable even more accessible and affordable for developers. We will continue to support developers to build blocks for free (e.g. connect blocks-cli etc.) and are looking to make the full custom blocks functionality - that pro users have - available to developers on a special developer plan. More exciting things to come!


Yep, that’s part of it!

1 Like

Hi @Harshit_Juneja

That’s wonderful to hear :tada:. And thank you for helping us on this journey as well by offering solutions to the community. Makes a world of difference.

If you want to have the same API key across all users, you can store the code directly in the source code of the block.

If you want the user to bring their own API key (like we do for the Twilio Send SMS block), you can store the user’s API key in globalConfig, which is a key-value store that’s scoped to that block installation.

Note that in either case, the credentials will be visible to all users of the block, since the API requests are made client-side.


With all the tools available, what types of people do you consider to be developers?

  • someone who writes a custom block?
  • someone who writes a script for scripting block?
  • someone who uses the Standard API?
  • someone who has an API key and puts it in a 3rd party app but might not write any code directly?
  • someone with creator permissions on a base?

Hi! I think the best place is to start a thread in this forum ( Our team regularly checks new topics, and in some cases there might be someone else who’s already run into the same issue.

Do you have formal names for the different APIs?
Having clear names can make discussions on the community forums easier.

I’ve been calling them the

  • Standard REST API (but the docs just call this the Standard API)
  • Scripting API
  • Custom Blocks API

Hi @Ashwin_Kumar,

You are asking the million dollar question! One of the blessings (and challenges) that we have at Airtable is how horizontal and flexible the product is. We serve small businesses and Fortune 500 companies alike. Often our beachhead into a company is serving a particular use case, or piece of their ‘stack’. Users then realize they can use Airtable to meet many of their other use cases too.

For larger customers, we often see folks replacing in-house built tools that would have taken much more engineering time and effort to build and maintain. Users are then empowered - whether they are technical or not - to modify the bases as needed. To your point, there is a lot of benefit from bringing in data from other services and being able to view and modify your data in a flexible tool like Airtable.

Hopefully that helps. Great question.


Good question! We refer to them in the same way (Standard API, Scripting API, Custom Blocks API). But it’s a good point that maybe “standard API” isn’t as descriptive now that there are other APIs.

And we are officially out of time! Thank you so much for joining us today.

We’ll be awarding gift cards to the 3 questions that received the most upvotes: @Matthew_Thomas, @Harshit_Juneja, @Jacob_Cannon. Look out for another AMA same time next week focused on design.


Thank you for hosting this session!

1 Like