Table of contents
- Provider structure
- Step-by-step implementation
- Provider attributes
- Abstract methods
- Provider types and capabilities
- Authentication configuration
- Testing your provider
- Best practices
- Common patterns
- Complete provider example
- Checklist
Provider structure
Each provider in Keep follows a specific structure:- Keep’s ProvidersFactory automatically discovers providers based on the directory naming convention (
*_provider
). - You don’t need to register them explicitly - just follow the naming pattern.
- The provider type is automatically extracted from the class name (for example,
ServiceNowProvider
→servicenow
).
Step-by-step implementation
1. Create provider directory
Create a new directory underkeep/providers/
with the pattern {service}_provider
:
2. Create the provider module
Createyourservice_provider.py
with the following structure:
3. Create the init.py File
Createkeep/providers/yourservice_provider/__init__.py
:
4. Add provider documentation
Createdocs/providers/documentation/yourservice-provider.mdx
following the documentation template.
Provider configuration fields are automatically documented through auto-generated snippets. Keep generates the snippet files in
docs/snippets/providers/
from the provider’s AuthConfig metadata and includes them in the documentation automatically.Provider architecture
Abstract methods
Every provider must implement these two abstract methods from BaseProvider:validate_config(self)
- Validates and processes the provider configurationdispose(self)
- Clean up resources when the provider is disposed of
Provider capabilities
Providers expose capabilities through standard methods:_notify(**kwargs)
- Send notifications or alerts_query(**kwargs)
- Query data from the provider_get_alerts()
- Fetch alerts for monitoringsetup_webhook(...)
- Configure webhook endpointsvalidate_scopes()
- Check provider permissionsexpose()
- Return parameters calculated during execution for use in workflows
The public methods
notify()
and query()
wrap the private implementations (_notify()
and _query()
) with additional capabilities like enrichment and error handling. Always implement the private methods.Provider discovery
Keep automatically discovers providers based on naming conventions:- Location:
keep/providers/
directory - Directory naming: Must end with
_provider
(for example,slack_provider
) - Main file: Must match directory name with
.py
extension (for example,slack_provider.py
) - No explicit registration needed - just follow the naming convention
Implementation examples
Validate_config()
Dispose()
Provider type extraction
The provider type is automatically extracted from your class name:YourserviceProvider
→yourservice
ServiceNowProvider
→service.now
DatadogProvider
→datadog
_extract_type()
method in BaseProvider.
Provider attributes
Providers should define the following class attributes:PROVIDER_DISPLAY_NAME
: String used for UI display (for example, “Slack”)PROVIDER_CATEGORY
: List of categories from the allowed values (see Provider Categories section)PROVIDER_COMING_SOON
: Boolean flag to mark providers as not ready (default: False)WEBHOOK_INSTALLATION_REQUIRED
: Boolean to make webhook setup mandatory in UI (default: False)PROVIDER_TAGS
: List of tags describing provider capabilities (for example, [“alert”, “messaging”])PROVIDER_SCOPES
: List of ProviderScope objects defining required permissionsPROVIDER_METHODS
: List of ProviderMethod objects for additional capabilities (see Provider Methods)FINGERPRINT_FIELDS
: List of field names used to calculate alert fingerprintsOAUTH2_URL
: OAuth 2.0 authorization URL if provider supports OAuth 2.0 authentication
Provider categories
Providers must specify one or more categories from the following list:Provider tags
Valid options forPROVIDER_TAGS
:
"alert"
- Provider handles alerts"ticketing"
- Provider manages tickets"messaging"
- Provider sends messages"data"
- Provider queries data"queue"
- Provider manages queues"topology"
- Provider provides topology data"incident"
- Provider manages incidents
Provider scope
Provider config
Base provider
Provider types and capabilities
Base provider types
Keep supports several base provider types, each with specific capabilities:-
BaseProvider (
keep/providers/base/base_provider.py
)- Basic provider capabilities
- Methods:
_notify()
,_query()
,_get_alerts()
- Use for: General integrations
-
BaseTopologyProvider (
keep/providers/base/base_provider.py
)- Extends BaseProvider
- Methods:
pull_topology()
- Use for: Services that provide infrastructure topology data
- Example: Datadog Provider (
keep/providers/datadog_provider/datadog_provider.py
)
-
BaseIncidentProvider (
keep/providers/base/base_provider.py
)- Extends BaseProvider
- Methods:
_get_incidents()
,_format_incident()
(static),format_incident()
(classmethod),setup_incident_webhook()
- Use for: Incident management systems
- Example: PagerDuty Provider (
keep/providers/pagerduty_provider/pagerduty_provider.py
)
Common capabilities
1. Notification (_notify
)
Send alerts or messages to external services:
2. Query (_query
)
Fetch data from external services:
3. Alert Fetching (_get_alerts
)
Pull alerts for monitoring:
4. Webhook support
Handle incoming webhooks:5. OAuth 2.0 support
Handle OAuth 2.0 authentication:6. Consumer providers
For providers that consume messages from queues or streams:Specialized base classes
Keep provides specialized base classes for specific provider types:Base topology provider
For providers that manage infrastructure topology and service dependencies:BaseIncidentProvider
For providers that manage incidents and incident response:get_incidents()
method is automatically provided by the base class and wraps _get_incidents()
. The format_incident()
class method handles provider loading and calls _format_incident()
.
Authentication configuration
Providers should define an authentication configuration class as a dataclass with proper field types and validation:Field validation
Keep provides built-in field validation through custom Pydantic field types:Validation Type | Field Type | Description | Example |
---|---|---|---|
"https_url" | HttpsUrl | Validates HTTPS URLs only | https://api.example.com |
"any_http_url" | pydantic.AnyHttpUrl | Validates any HTTP/HTTPS URL | http://example.com |
"no_scheme_url" | NoSchemeUrl | Validates URLs without scheme | example.com:8080 |
"port" | UrlPort | Validates port numbers (1-65535) | 443 |
"multihost_url" | MultiHostUrl | Validates multi-host URLs | mongodb://host1:27017,host2:27017 |
"no_scheme_multihost_url" | NoSchemeMultiHostUrl | Multi-host URLs without scheme | host1:9092,host2:9092 |
- Import the appropriate field type from
keep.validation.fields
- Use it as the field type annotation
- Add the corresponding validation string in metadata
Metadata fields reference
required
: Whether the field is mandatorydescription
: Field description shown in UIsensitive
: Whether to mask the field value (for secrets)hidden
: Whether to hide the field in UIdocumentation_url
: Link to relevant documentationhint
: Help text for usersvalidation
: Validation type string (see preceding table)type
: UI input type (for example, “select” for dropdown)options
: List of valid options for select fieldsconfig_main_group
: Group name for organizing fields in UIconfig_sub_group
: Sub-group name for nested organization
The validation system ensures that configuration values are valid before Keep instantiates the provider. Invalid values are rejected with clear error messages, improving the user experience and preventing runtime errors.
Testing your provider
1. Unit test
Createtests/test_yourservice_provider.py
:
2. Integration test
Test with the provider factory:3. Manual testing
You can test your provider by running it directly:if __name__ == "__main__":
block allows you to test provider initialization and basic capabilities.
Add a test block to your provider for direct execution:
Best practices
1. Error handling
Always handle API errors gracefully:2. Logging
Use the provider’s logger:3. Configuration validation
Validate configuration invalidate_config()
:
4. Alert formatting
When returning alerts, use Keep’s standard format:5. Secrets management
Never hardcode secrets. Use environment variables or configuration:Common patterns
1. Provider health checks
Implement health monitoring using theProviderHealthMixin
:
The health check mixin is particularly useful for monitoring providers that collect topology data or handle high volumes of alerts.
2. Pagination
Handle paginated API responses:3. Rate limiting
Respect API rate limits:4. Caching
Cache frequently accessed data:5. Webhook signature verification
Verify webhook authenticity:6. Exposing runtime parameters
Use theexpose()
method to make runtime-calculated values available to workflows:
Complete provider example
Here’s a minimal example of a complete provider implementation:File references
- Base Provider Classes:
keep/providers/base/base_provider.py
- Provider Models:
keep/providers/models/
- Provider Factory:
keep/providers/providers_factory.py
- Provider Exceptions:
keep/exceptions/provider_exception.py
- Example Providers:
- Simple:
keep/providers/slack_provider/slack_provider.py
- Complex:
keep/providers/datadog_provider/datadog_provider.py
- Database:
keep/providers/clickhouse_provider/clickhouse_provider.py
- Incident:
keep/providers/pagerduty_provider/pagerduty_provider.py
- Topology:
keep/providers/datadog_provider/datadog_provider.py
- Simple:
- Tests:
tests/test_*_provider.py
- Documentation:
docs/providers/documentation/
- Additional Docs:
docs/providers/adding-a-new-provider.mdx
docs/providers/provider-methods.mdx
docs/providers/linked-providers.mdx
Checklist
- Create provider directory and files
- Implement AuthConfig class with proper metadata
- Implement provider class with required methods
- Add provider to
__init__.py
- Set appropriate PROVIDER_DISPLAY_NAME, PROVIDER_CATEGORY, and PROVIDER_TAGS
- Implement
validate_config()
anddispose()
- Add at least one capability (
_notify
,_query
, or_get_alerts
) - Create documentation in
docs/providers/documentation/
- Write unit tests
- Test with provider factory
- Handle errors gracefully
- Add logging statements
- Validate in Keep UI
- If supporting webhooks, implement
_format_alert()
static method - If supporting OAuth 2.0, set OAUTH2_URL as class attribute
- Consider implementing
validate_scopes()
for scope validation - Consider implementing
get_provider_metadata()
for provider versioning
Getting help
- Review existing providers for examples
- Check the base provider classes for available methods
- Look at test files for testing patterns
- Ask in Keep’s GitHub discussions or issues
- Review the Provider Methods documentation for advanced capabilities
- Understand Linked vs Connected Providers