Skip to main content
This guide explains how to create a new provider for Keep. Providers are integrations that allow Keep to interact with external services for alerting, querying data, managing incidents, or building topology maps.

Table of contents

Provider structure

Each provider in Keep follows a specific structure:
Important Notes:
  • 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, ServiceNowProviderservicenow).

Step-by-step implementation

1. Create provider directory

Create a new directory under keep/providers/ with the pattern {service}_provider:

2. Create the provider module

Create yourservice_provider.py with the following structure:

3. Create the init.py File

Create keep/providers/yourservice_provider/__init__.py:

4. Add provider documentation

Create docs/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:
  1. validate_config(self) - Validates and processes the provider configuration
  2. dispose(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 monitoring
  • setup_webhook(...) - Configure webhook endpoints
  • validate_scopes() - Check provider permissions
  • expose() - 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:
  • YourserviceProvideryourservice
  • ServiceNowProviderservice.now
  • DatadogProviderdatadog
This happens via the _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 permissions
  • PROVIDER_METHODS: List of ProviderMethod objects for additional capabilities (see Provider Methods)
  • FINGERPRINT_FIELDS: List of field names used to calculate alert fingerprints
  • OAUTH2_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 for PROVIDER_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:
  1. BaseProvider (keep/providers/base/base_provider.py)
    • Basic provider capabilities
    • Methods: _notify(), _query(), _get_alerts()
    • Use for: General integrations
  2. 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)
  3. 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:
Note: The 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: To use validation:
  1. Import the appropriate field type from keep.validation.fields
  2. Use it as the field type annotation
  3. Add the corresponding validation string in metadata
Example implementations:

Metadata fields reference

  • required: Whether the field is mandatory
  • description: Field description shown in UI
  • sensitive: Whether to mask the field value (for secrets)
  • hidden: Whether to hide the field in UI
  • documentation_url: Link to relevant documentation
  • hint: Help text for users
  • validation: Validation type string (see preceding table)
  • type: UI input type (for example, “select” for dropdown)
  • options: List of valid options for select fields
  • config_main_group: Group name for organizing fields in UI
  • config_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

Create tests/test_yourservice_provider.py:

2. Integration test

Test with the provider factory:

3. Manual testing

You can test your provider by running it directly:
The 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 in validate_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 the ProviderHealthMixin:
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 the expose() method to make runtime-calculated values available to workflows:
This allows workflows to access the actual timestamps used in queries, not just the relative time strings.

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
  • 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() and dispose()
  • 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