Extension review process
This guide covers the process that Airtable follows when reviewing extension submissions to the marketplace.
The Airtable team carefully reviews all extensions that are submitted to the Marketplace, to protect Airtable users from potentially buggy or malicious extensions, and to ensure that Airtable users continue to find the Marketplace to be a consistently valuable source of extensions that solve their problems. We also want to help make sure that extension developers have the best possible chance of reaching as many users as possible with extensions.
To help give a sense of what the extension review process entails, and better prepare extensions for successful submission, this is how our review process works.
Note: This process is subject to change as we continue to improve our review workflow. All Airtable development is also subject to our Developer policy.
The review process
There are four main steps in the review process. After running block submit
, the extension submission gets added to our internal review pipeline (and yes - we use Airtable to track it!). We then run the following reviews, in sequence:
- Functionality review: We get the extension up-and-running in a test base, just to make sure that it does roughly what it says it does.
- QA: We put the extension through its QA paces, looking for potential edge-case bugs and vulnerabilities.
- Security: We look through the actual code of the extension, looking for any potentially-malicious code, ensuring that it doesn't do anything unexpected, and looking for things like
npm
dependency security flaws and deprecated feature usage. - Design: We take a high-level pass at the extension's overall design, looking to make sure the extension is generally usable and also to offer suggestions for how to improve the overall user experience.
If the extension fails any of these reviews, we'll send back the feedback to the extension developer, and the extension can be re-submitted with updated code. For extremely minor tweaks, we may jump back to the same review, but for any larger revisions we will start the review process again. For this reason, we recommend developers carefully test their extension as thoroughly as possible before submitting to the review process.
How do extensions pass the review?
In general, for an extension to be approved, it must adhere to all of the following guidelines:
The extension should carefully follow the guidelines described in the Polishing and sharing your extension guide.
The extension developer must provide sufficient help/support information to address typical usage of the extension.
- If the extension is at all complicated to set up or use, the developer must provide adequate information via their support website or in the extension description to help the user use the extension.
The extension must be bug-free for its supported critical user journeys.
- Though nothing in software is truly bug free, extensions must at least not exhibit any bugs when walking through its most likely-used features.
The extension must be sufficiently generalized in order to be used in bases with many different possible structures.
- If the extension pulls data from specific fields in a base, it must generally be possible for the user to easily configure it to fit their particular base schema.
- Extensions may require certain types of fields to be present in order to function - for example, a scheduling extension might require two date fields (for start and end date) and one text field (for event title). But the extension should allow the user to map which fields in their particular base should be used, and not expect specific field names.
The extension must only read or write data that it specifically needs to function.
- Extensions must not read any additional data from the base beyond that which is required.
- Extensions must not make any changes to the data in the base unless the user obviously intends to and would understand the ramifications.
The extension must only access the network if absolutely necessary to fulfill its core function.
- Extensions must not send any information stored in the base over the network unless part of its core functionality, and clearly indicated to the user.
The extension must not do any dynamic code generation - if it does, the developer must work directly with us in a more detailed review process.
- Using
eval
ornew Function
is not allowed - Dynamically inserting script tags is not allowed.
- Creating Web Workers is not allowed.
- Using
document.execCommand
is not allowed. - Dynamically including packages at runtime is not allowed
The extension must make all network requests over HTTPS.
The extension's npm dependencies must be clearly legitimate and low-risk.
npm audit
must return no vulnerabilities.- Dependencies should be legitimate and generally widely-used.
The extension should adhere to our Content Security Policy:
- If you open the browser's dev console after using the extension for a while, there should be no CSP violations.
Associated assets must accurately portray the extension itself.
- Screenshots must resemble the extension itself.
Extension must be relatively clean and polished.
- Extension should be visually appealing, as appropriate for its functionality and audience.
- Generally, the extension should try to use the Airtable UI kit if appropriate, in order to ensure a consistent and high-quality user experience. Extensions may choose to use their own look-and-feel as long as it doesn't negatively impact the UX.
Extension must not include any advertising or other non-functional UI.
- Extension cannot include any ads or other visuals that distract from its functional purpose.
If the extension requires the user's Airtable API key, it should be clear to the user that this entails significant risk.
- The API key input field should not be obfuscated.
- There should be some notification to the user that this will allow the extension to read and write to the base.
Extensions must include privacy policies and terms of service from the developer.
FAQs
How long does the review process take?
End-to-end the review process can currently take anywhere from a few days to a few weeks - depending on how large and complex the extension is, how many back-and-forths are required to get it in shape for approval, and how many other extensions are currently in the review pipeline.
There are a few things that extension developers can do to help drive down the turnaround time for review:
- Make sure the extension closely follows the recommendations in this guide as well as in our Polishing and sharing your extension guide
- Include robust testing instructions for the extension with its submitted metadata, to help our QA team.
- Only submit one version of the extension, once it's ready to go. Multiple code submissions significantly slow down our review process.
We're actively working on improving our review process and scaling out our reviewing capacity and hoping to drive down review times over time.
How do I submit updates to my extension once it's been published?
If your extension is already approved, you can simply run block submit
again to upload the latest code to us. We'll run it through the extension review process just as any other extension. For this reason, we currently recommend leaning towards fewer, larger updates rather than more frequent, smaller updates.
Once your update is published, it will automatically be pushed to all of its users when they refresh the page or load the extension again for the first time. For this reason, pay careful attention to any migrations of the globalConfig
that your extension might need to manage when it gets updated to the new version.
Can I submit code updates while the extension is in review?
We generally wouldn't recommend this - depending on the size of the update, it will tend to force us to restart the review from the beginning, and therefore move your extension to the end of the review queue. It would generally be better to collect updates into a single submission, and submit the update to us once your extension is initially published in the Marketplace.