Configuration
Learn about the gitbook-manifest.yaml file your integration uses.
Integrations are defined through a file called gitbook-manifest.yaml
. This file is automatically created through the CLI when creating a new integration.
*required
Name*
The name of your integration. Must be unique across all GitBook integrations.
Example:
Title*
The title of your integration.
Example:
Description*
A short description for your integration.
Example:
Organization*
The id
or subdomain
of the organization that owns this integration.
Example:
Visibility*
The visibility for your integration.
private
Default for new integrations. Only members from the organization defined in the integration's manifest will be able to install the integration.
unlisted
Members from any organization can install the integration. The integration will only be available to install via it's shared install link.
public
Members from any organization can install the integration. Integrations wanting to submit to the marketplace must use this visibility.
Example:
Scopes*
The scopes your integration has permissions for.
Example:
You may see the scope site:script:inject
throughout GitBook owned integrations—This scope is only available for internal GitBook use.
Building integrations that inject JavaScript into a space or page are not possible to build at this time.
Script
The main script to execute for your integration. Should contain the call createIntegration()
.
Example:
Blocks
Component block(s) referenced by name
to render in the ( ⌘ + / ) menu. See createComponent()
to learn more.
Example:
Categories
A list of categories your integration falls into.
Example:
Summary
A summary for your integration displayed on the installation page. Supports Markdown.
Example:
Icon
A locally referenced icon for your integration. Asset must be located alongside the code for your integration.
Example:
Preview Images
A list of locally referenced assets to display on the installation page for your integration.
Example:
External Links
A list of URLs to display on the installation page for your integration. Each link requires a label
and a url
.
Example:
Configurations
The configurations key allows you to specify specific steps and configurations for your integration through it's environment
.
You're able to set up default configurations under the configurations.account
key, and site-specific configurations through the configurations.site
key.
All configurations accept properties
, which are named keys used to describe the different steps your user will go through as they install your integration. You can also name these properties in a required
key to enforce certain configurations.
You can create as many properties as you would like, and can be of the following:
string
String configurations can be used to collect user input. You can use optional keys enum
or completion_url
to provide a list of items from a dropdown list instead than an input.
enum
allows you to specify a list of items, while completion_url
allows you to fetch options from an endpoint. See the Slack configuration to learn more.
number
boolean
button
Button configurations can be used if you need to set up an OAuth connection with a provider in order to use your integration. See createOAuthHandler()
for more information.
Example Configuration:
Secrets
A list of secrets or environment variables that your integration might need in order to function. By default, environment variables are not loaded into GitBook's Manifest file.
We recommend using a package like dotenv-cli
to include environment variables in your integrations configuration through an .env
file when using the cli
.
See the Linear integration for an example.
Example:
Installation & Configuration flow
During the installation flow, an event installation_setup
is triggered as soon as the integration is installed for the first time. You can identify the configuration as being incomplete by checking environment.installation.status != 'active'
.
This event (installation_setup
) is triggered every time the user edits one property of the configuration. The status will become active
once the configuration pass the validation with the schema.
Last updated
Was this helpful?