Learn how to configure the settings required to connect an integration
Connector-wide settings are required for configuring the behaviour of a connector across all its capabilities. These settings often include unique identifiers for tenants, server configurations, or other API-specific parameters required for the connector to function correctly.Purpose of Connector-Wide Settings
- Tenant Identification: Many APIs require a unique identifier for the customer’s account or organization (e.g.,
site_id,customer_code). Sometimes this value is returned withinvalidate_credentials, in cases when the API does not return a valid identificator. - Server Configuration: For APIs that can be hosted on-premises or in different environments, server details may be required (e.g.,
server_name,instance_url). - API-Specific Parameters: Some APIs may require additional configuration parameters for authentication or functionality.
Implementing Connector-Wide Settings
Connector-wide settings are typically implemented using a Pydantic model in thesettings.py file of each connector. Here’s an example from the abc connector:
Key Components of Connector-Wide Settings
- Pydantic BaseModel: Use Pydantic’s
BaseModelas the base class, to ensure proper type checking and validation. - Required Fields: Define fields that are always required for the connector to function (e.g.,
site_id). - Optional Fields: Include fields that have default values or are not always required (e.g.,
server_name,auth_setting). - Field Metadata: Use
pydantic.Fieldto provide additional information:title: A user-friendly name for the field.description: Detailed explanation of the field’s purpose and how to obtain its value.default: Default value for optional fields.
Integrating Settings with the Connector
To use these settings across all capabilities, include them in theIntegration configuration:
Best Practices for Connector-Wide Settings
- Sensible Defaults: Where possible, provide default values that work for most common scenarios.
- Validation: Use Pydantic validation features to ensure that provided settings meet the required format and constraints.
- Flexibility: Design settings to accommodate different deployment scenarios (e.g., cloud vs. on-premises).
- Security: Be cautious about default values for sensitive information. Use
AnnotatedFieldwhere applicable.
Accessing Settings in Capabilities
To use these settings within capability functions, you can access them using theget_settings helper: