Understanding commonly used extension points in Splunk apps
Extension points in Splunk apps deliver new reusable functionality that is not otherwise part of the Splunk platform by integrating external code. All extension points were developed out of necessity and by various Splunk groups, with little collaboration, which is the reason that there are differences in extension points APIs. However, all are described in the Splunk developer documentation. If an extension point is not in the documentation, then it's a non-sanctioned use and we don't recommend implementing it.
This article goes over four of the most commonly used extension points, looking at the different implementations and characteristics of each so that you can make the right decisions when developing your own apps.
Extension points
Data inputs
Create a custom data input if you have any of the following objectives:
- Query a database, web service, or API
- Reformat complex data
- Stream results from a command, such as
vmstatoriostat - Remove or elide sensitive information from data before ingesting it
- Handle special characters in inputs
Scripted
Use this to gather data from a system and to debug data.
- Runs on schedule
- Simple to implement
- Static, with limited configuration options
- Isn’t managed by API but rather written in the app
- No multi-platform support
- User access can be managed
Modular
You will need to write these on your own with a separate instance of it running for each use case.
- Configurable, using info from each machine
- Configuration done by UI or API
- REST API managed
- Multi-platform support
For more information on data input extension points, see Create custom data inputs for Splunk Cloud Platform or Splunk Enterprise and Modular inputs basic example.
REST endpoints
The Splunk Enterprise REST API provides functionality such as running searches and managing knowledge objects and configurations. You can create a custom endpoint to introduce additional capabilities into the Splunk Enterprise REST API to meet your specific needs.
Extensible administration interface
With this method, changes take place in the file system of the app.
- Dynamically manage your app's custom configuration files (if you have the right permissions)
- Base Python class:
MConfigHandler - Two execution modes:
- Persistent - Use this when you need to invoke an endpoint often. It has faster execution than non-persistent and is good for use with the libraries provided in the Splunk platform.
- Non-persistent - This can cause some performance problems, but it is easier to maintain than persistent and is good for a non-conventional library that is not included with the Splunk platform. Use this for endpoints you don't need to invoke very often.
Script endpoint
This methods lets you call other APIs and interact with the Splunk platform.
- Implicit (providing Python import string)
- Base class:
splunk.rest.BaseRestHandler
- Base class:
- Explicit (by a file name)
- Return result to the stdout of a Python script
- Persistent
- scripttype: persist
- base class:
PersistentServerConnectionApplication
For more information on REST endpoint extension points, see Extend the Splunk platform REST API with custom endpoints.
Custom search commands
Custom search commands let you perform additional data analysis in the Splunk platform. You can implement custom search commands by creating Python scripts that run alongside splunkd at search time.
V1 (non-chunked results)
This is not recommended because you need to write everything on your own. However, many applications are still using it, so it cannot be deprecated.
- Needs manual data serialization from stdin (standard input)
- No support
- Limited helper functions in SDK
V2 (chunked results)
It is easy to implement the following types of commands this way with the Splunk Enterprise SDK for Python.
- Streaming
- Processing
- Generating
- Transforming
For more information on search command extension points, see Create custom search commands for apps in Splunk Cloud Platform or Splunk Enterprise.
Custom alerts
Custom alert actions are user-defined alert actions that allow you to extend the Splunk platform with specialized alerting functionality. You can implement a custom alert action in a script and package the solution in a Splunk app.
Scripted global alerts
- Deprecated
- Manual data serialization from stdin
- Limited helper functions and tooling in SDK
- No native UI configuration
- Requires manual deployment and restart of Splunk for changes to take effect
Modular alerts
- Modern solution to alerting problems (since Splunk platform 6.3)
- No manual serialization
- Better tooling (SDK)
- Integrated with the Splunk alerting system and UI for configuration (supports default parameters and user input)
- Runtime configuration reload and app deployment without needing to restart the Splunk platform
For more information on alert extension points, see Create custom alert actions for Splunk Cloud Platform or Splunk Enterprise.
Additional resources
Now that you have an introduction to common extension points, watch the full .conf25 talk, Splunk extension points: Where to find and how to use them. This talk goes into more detail about these and offers general best practices for good app development.
In addition, these resources might help you implement the guidance in this article:
- Splunk Developer Documentation: What you can do in a Splunk app

