Building your first app with App Configuration
Follow a step-by-step walkthrough for building a Benchling App that uses App Configuration. This guide shows how to define configuration, connect it to your app logic, and test the resulting behavior.
For this tutorial we’ll use the simple app from Building your first Benchling App. To review, that app updates the “Species” field for all DNA sequences of a certain schema. The full code is included here for reference:
What happens if you try to install and run this app on a different Benchling tenant? Two lines cause problems:
entity_schema_to_check = "ts_AcqPy93F"hardcodes a tenant-unique ID for the entity schema. A user installing this app on a different tenant will have a different ID value, and might have an entirely different type of schema whose “Species” field they want autofilled.current_species = sequence.fields["Species"].valuereferences a schema field named “Species” exactly. On another tenant the field names are unlikely to match. The field might be called “Organism” instead.
An app manifest lets us remove both tenant-specific dependencies. First, create a YAML file with a manifest that includes configuration options to capture these details:
This defines two configuration options: a field of type entity_schema, and a field
named Species on that schema. The goal is to reference these instead of tenant-specific
identifiers, so Benchling users can supply the correct values themselves. To do that, we
install the app using this manifest:


With the app created from the manifest, follow the steps in Managing and Sharing Benchling Apps to complete the installation. Then finish configuring the app: click the “Connections” sidebar option, then the “Apps” tab, then “My App Name”, then the “Configuration” tab.

Our schema configuration options, defined in the app manifest, are configurable from this page. Select the schema on this tenant that the app should interact with:

Once the schema is selected, choose the field on that schema the app should use, then submit the configuration:



We’re doing this ourselves for the tutorial, but the power of App Configuration is that a tenant admin can perform these steps themselves, which is what lets you build tenant-agnostic apps installable by multiple customers.
Updating app code to use configuration
The example app has its tenant URL, credentials, and app ID hardcoded as variables for demonstration purposes. This isn’t a best practice: using App Configuration requires storing these in a secure parameter store accessible by your app. We’ve omitted the details of that process here, since it’s specific to your app’s deployment environment.
Using the app’s credentials, app ID, and tenant URL, apps can read their own configuration through the Get app configuration items endpoint. The response looks like this:
Reading app configuration in V3
V3 is the recommended API for new development. It exposes app configuration read-only, as app config values rather than configuration items: GET /api/v3/app-config-value/items and GET /api/v3/app-config-value/{app_config_value_id}. Each value carries a path locating it in the configuration hierarchy and a valueData holding the value itself, typed by the app’s config spec. That is a different shape from the V2 response below, not a renamed one.
There is no V3 write path for app configuration, so anything that sets a config value stays on V2. The examples on this page are V2 throughout.
The top-level appConfigurationItems is an array of objects corresponding to all
configuration options, each including metadata and the value selected by the tenant
admin. We’re specifically interested in linkedResource, an object holding the API ID
and name values we had previously hardcoded. We can update the app to pull this
configuration dynamically at startup:
Both original problems are now resolved:
dna_sequences.list(..., schema_id=entity_schema_to_check)uses the resource ID from App Configuration instead of a hardcoded ID value.sequence.fields[species_schema_field_name].valuedepends on the field listed in App Configuration instead of the hardcoded name"Species".
These changes let the app be installed and configured on any Benchling tenant without code changes. Users can also rename fields and change schemas without affecting the app’s functionality, as long as they update the corresponding values in App Configuration.
Each app configuration item also includes other metadata like id and apiURL. In
future guides we’ll cover best practices for interacting with app configuration options
in a more abstract way.