.png)
Splunk Integration Guide
Integrate Splunk with enterprise systems through REST APIs, SPL searches, HTTP Event Collector, and selected alert webhooks.
Splunk integration options at a glance
Splunk provides REST APIs for administration, search, configuration, authentication, knowledge objects, and data inputs. Its Search APIs support synchronous exports and asynchronous search jobs that Martini can poll and retrieve in manageable result sets. Splunk HTTP Event Collector accepts event data over HTTP or HTTPS, including batched payloads with index, source, sourcetype, host, and timestamp metadata. Selected alert scenarios can invoke webhook-style HTTP actions, although Splunk does not provide a universal webhook for every indexed event. Martini can secure these flows with Splunk tokens, HEC tokens, Basic Authentication, or session keys stored as protected secrets.
| Integration point | Supported by Splunk? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Manage search jobs, retrieve results, read indexes, administer selected resources, manage saved searches and alerts, configure selected inputs, and use authentication endpoints. | Martini can consume Splunk REST endpoints over HTTPS, map request and response data, and orchestrate multi-step operations in workflows. |
| Search APIs and SPL | Yes | Submit SPL searches synchronously or asynchronously, poll search jobs, export results, and synchronize security, operational, or usage data. | Martini can submit validated SPL, poll asynchronous jobs, retrieve JSON, XML, or CSV results, apply checkpoints, and write transformed data to target systems. |
| HTTP Event Collector | Yes | Ingest application, infrastructure, security, and other event data over HTTP or HTTPS using HEC tokens and event metadata such as index, source, sourcetype, host, and time. | Martini can transform source payloads into HEC envelopes, send individual or batched events, and apply retry and failure-handling policies. |
| Bulk and asynchronous processing | Yes | Process multiple HEC events per request and execute long-running searches through asynchronous search jobs and result retrieval. | Martini workflows can batch data, poll job status, retrieve result chunks, enforce timeouts, and persist checkpoints for recurring synchronization. |
| Webhooks and outbound callbacks | Limited | Invoke an HTTP endpoint from selected configured Splunk alert actions. This is not a universal notification stream for every indexed event or Splunk object. | Martini can expose an API or receive the webhook-style request in a workflow, validate and deduplicate it, enrich the alert, and invoke downstream APIs. |
| File and attachment APIs | Limited | Self-managed Splunk deployments can monitor files and support file-oriented ingestion patterns, but a general-purpose attachment API was not confirmed. | Martini can process supported file inputs or call documented endpoints when available, while treating file monitoring as deployment-specific rather than a general attachment integration. |
| Database and analytics access | Limited | Splunk DB Connect provides JDBC-based database integration as a separate Splunk component; it is not a general Splunk platform database API. | Martini should normally use Splunk REST APIs or HEC. Where DB Connect and the required database are provisioned, Martini can use supported database integration patterns separately. |
| Authentication | Yes | Use bearer authentication tokens, HEC tokens, Basic Authentication, or session keys according to the Splunk deployment and endpoint. | Martini can store credentials and tokens in protected secrets, apply endpoint-specific headers, and separate development, test, and production access. |
How Splunk exposes data and business events
Splunk REST APIs
Splunk exposes REST resources for search, administration, configuration, authentication, knowledge objects, data inputs, saved searches, and alerts. Endpoint availability and permissions vary between Splunk Enterprise and Splunk Cloud Platform.
Martini implementation pattern
Martini implementation pattern: Martini consumes the deployment-specific REST endpoint with a protected token or other confirmed authentication method, maps request parameters and response payloads, and orchestrates follow-up calls in a workflow. It can expose a controlled Martini API when other systems need a stable integration boundary.
Implementation sequence
Splunk Search APIs
Splunk searches use Splunk Processing Language, or SPL. Searches may run synchronously through export-style endpoints or asynchronously as search jobs that are later polled and retrieved.
Martini implementation pattern
Martini implementation pattern: a scheduled or API-triggered workflow submits bounded and validated SPL, polls the search job when required, retrieves result pages or chunks, and transforms JSON, XML, or CSV output for downstream systems. Durable checkpoints prevent repeated processing across recurring searches.
Implementation sequence
HTTP Event Collector
Splunk HEC accepts event data over HTTP or HTTPS using a HEC token. Events can include index, source, sourcetype, host, timestamp, and other metadata, and multiple events may be submitted in a request.
Martini implementation pattern
Martini implementation pattern: Martini receives source data from an application, database, file, or messaging system, validates required event metadata, maps records into HEC JSON, and submits controlled batches. Retry policies distinguish transient transport failures from invalid payloads and preserve source identifiers for replay.
Implementation sequence
Splunk alert webhooks
Splunk supports webhook-style alert actions for selected alert scenarios. These actions are configured for alert conditions and do not provide universal notifications for every indexed event or every Splunk object.
Martini implementation pattern
Martini implementation pattern: Martini exposes a secured API endpoint or webhook-oriented workflow, validates the incoming alert and authentication context, applies severity and routing rules, enriches the alert through other APIs, and creates or updates a downstream object. Idempotency keys prevent duplicate actions when requests are retried.
Implementation sequence
Splunk DB Connect
Splunk DB Connect provides JDBC-based database integration as a separate Splunk component. It is not a general-purpose database API for every Splunk deployment and should be confirmed as part of the target architecture.
Martini implementation pattern
Martini implementation pattern: when DB Connect and the required database are provisioned, Martini can coordinate database-oriented workflows using supported database access patterns. For direct Splunk integration, REST APIs and HEC remain the preferred mechanisms described in the supplied research.
Implementation sequence
Common Splunk integration patterns
Pattern 1: Ingest application and infrastructure events
When to use this pattern
Use this pattern when applications, databases, cloud services, or messaging systems need to send normalized operational data to Splunk for search and analysis. It is appropriate for real-time or scheduled batches where HEC is available.
Integration direction
Example Mapping
| Splunk Field | Canonical Field | Target Field |
|---|---|---|
| eventTimestamp | event.time | time |
| serviceName | service.name | source |
| eventType | event.type | sourcetype |
| payload | event.data | event |
Martini implementation pattern
A Martini workflow receives or retrieves source data, validates timestamps and routing metadata, maps each item into a HEC envelope, and submits bounded batches. It applies index and sourcetype business rules, retries transient failures with backoff, and records rejected items and source correlation identifiers for replay.
Martini capabilities used
- workflows
- API consumption
- data mapping
- business rules
- error handling
- secure secrets configuration
Pattern 2: Synchronize Splunk search results
When to use this pattern
Use this pattern when a downstream application or database needs security findings, infrastructure summaries, usage data, or alert-related results from Splunk. It supports recurring incremental synchronization through scheduled SPL searches.
Integration direction
Example Mapping
| Splunk Field | Canonical Field | Target Field |
|---|---|---|
| result._time | observedAt | occurred_at |
| result.host | assetIdentifier | configuration_item |
| result.severity | priority | priority |
| result.event_id | sourceCorrelationId | external_id |
Martini implementation pattern
A scheduled Martini workflow builds a bounded, validated SPL query using a durable time and tie-breaker checkpoint, creates or exports a search, polls asynchronous status, and retrieves results in chunks. It maps and enriches each result, upserts the target object, and advances the checkpoint only after successful processing.
Martini capabilities used
- scheduled workflows
- API consumption
- data mapping
- pagination and checkpointing
- business rules
- retry handling
Pattern 3: Route Splunk alerts into incident response
When to use this pattern
Use this pattern when selected Splunk alert conditions should create or update incidents in ServiceNow, Jira, PagerDuty, or another operational application. It relies on configured Splunk alert actions rather than a universal event webhook.
Integration direction
Example Mapping
| Splunk Field | Canonical Field | Target Field |
|---|---|---|
| alert_name | alert.ruleName | short_description |
| severity | alert.priority | urgency |
| search_id | alert.correlationId | correlation_id |
| result.host | affectedAsset | cmdb_ci |
Martini implementation pattern
Splunk invokes a secured Martini API endpoint for a selected alert. Martini validates the request, checks the correlation key, applies severity and assignment rules, enriches context through REST APIs, and creates or updates the downstream incident. Transient failures are retried while permanent validation failures are recorded for review.
Martini capabilities used
- APIs
- webhook handling
- validation
- data mapping
- orchestration
- idempotency
- error handling
Pattern 4: Enrich operational signals across systems
When to use this pattern
Use this pattern when Splunk contains the operational signal but another system owns customer, identity, asset, or incident context. It can be initiated by an alert or scheduled search and can return enriched information to a target application or Splunk.
Integration direction
Example Mapping
| Splunk Field | Canonical Field | Target Field |
|---|---|---|
| host | assetOrSubjectId | asset_id |
| user | principalId | user_id |
| source | signalSource | source_system |
| risk_score | riskScore | risk_score |
Martini implementation pattern
Martini receives or retrieves the signal, calls the relevant system APIs for context, applies enrichment and routing rules, and writes the combined result to the operational owner. It can also submit additional context to Splunk HEC, with safeguards against recursive processing and duplicate updates.
Martini capabilities used
- workflow orchestration
- REST API consumption
- data enrichment
- mapping and transformation
- conditional routing
- error handling
Applications commonly integrated with Splunk
Splunk commonly participates in observability, security, and operational workflows with named enterprise applications. Martini can orchestrate these integrations through each system's documented APIs, webhooks, files, or messaging endpoints without requiring a dedicated Splunk connector.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| ServiceNow | Create or update incidents from actionable Splunk alerts and use ticket status or configuration context in operational workflows. | Splunk → Martini → ServiceNow | Receive a Splunk alert or retrieve matching search results, validate and deduplicate the alert, map severity and ownership fields, then call ServiceNow APIs. Persist correlation identifiers and retry transient failures without creating duplicate incidents. |
| Salesforce | Correlate application or customer-impacting events with Accounts, Contacts, Cases, and related Salesforce objects. | Splunk → Martini → Salesforce | Run a bounded SPL search or receive an alert, enrich the result with Salesforce API lookups, apply case-creation rules, and map the result into Salesforce. Store the Splunk search or alert identifier alongside the Salesforce Case identifier. |
| Jira | Create Jira issues from actionable Splunk alerts and synchronize issue ownership or lifecycle status. | Splunk → Martini → Jira | Expose a Martini API for selected Splunk alert actions, normalize the alert payload, map severity and assignment values, and call Jira APIs. Use a stable alert or correlation identifier for idempotency and route rejected requests to error handling. |
| Okta | Send identity and authentication events to Splunk and use selected Splunk detections to initiate identity-related workflows. | Okta → Martini → Splunk | Consume Okta event data, transform it into Splunk HEC envelopes with consistent source and sourcetype values, and submit batches using a protected HEC token. For remediation, route selected Splunk alerts through Martini to Okta APIs under least-privilege credentials. |
| Amazon CloudWatch | Centralize AWS operational and security telemetry in Splunk and correlate it with application events. | Amazon CloudWatch → Martini → Splunk | Receive or retrieve AWS monitoring data, normalize timestamps and resource identifiers, map the payload into HEC event envelopes, and submit bounded batches. Apply backoff for throttling and retain source correlation values for troubleshooting. |
| Microsoft Azure Monitor | Ingest Azure platform and application telemetry into Splunk and correlate it with enterprise operational data. | Microsoft Azure Monitor → Martini → Splunk | Schedule retrieval or receive source notifications, transform Azure dimensions into Splunk fields, and send events to the appropriate index and sourcetype through HEC. Use environment-specific secrets and validate the target index before ingestion. |
| Kubernetes | Collect cluster, container, and workload telemetry in Splunk for operational monitoring and security analysis. | Kubernetes → Martini → Splunk | Process Kubernetes telemetry from an API, file, or messaging source, standardize namespace, pod, host, and workload fields, and submit events in controlled HEC batches. Separate transient ingestion errors from malformed payloads and preserve failed batches for replay. |
| PagerDuty | Route Splunk alert conditions into incident response workflows and synchronize acknowledgement or escalation state. | Splunk → Martini → PagerDuty | Receive selected Splunk alert actions, map urgency and service fields to PagerDuty event data, and call the PagerDuty API. Store the deduplication key and response identifiers, then process lifecycle callbacks or scheduled status checks where configured. |
How to build a Splunk integration in Martini
Objective
Establish access to the correct Splunk Enterprise or Splunk Cloud endpoint and configure least-privilege credentials for the required REST or HEC operations.
Instructions in Martini
- Confirm the deployment-specific endpoint, TLS requirements, proxy rules, and network allowlists.
- Choose a bearer token, HEC token, Basic Authentication, or session-key flow appropriate to the endpoint.
- Store tokens, credentials, and certificates in Martini secrets or protected environment configuration.
- Limit Splunk roles and capabilities to the indexes, searches, and resources required by the workflow.
Objective
Select an event-driven, scheduled, or API-led starting point based on whether the integration receives selected alert notifications or polls Splunk data.
Instructions in Martini
- Use a Martini API or webhook-oriented workflow for selected Splunk alert actions.
- Use a scheduler for recurring SPL searches and incremental synchronization.
- Use an inbound application, file, database, or messaging trigger when sending events to HEC.
- Define the expected frequency, time window, and checkpoint strategy before implementation.
Objective
Receive an alert request, submit an SPL search, poll a search job, or collect source data that will be written to Splunk.
Instructions in Martini
- Validate incoming alert payloads and reject malformed or unauthorized requests.
- Submit bounded SPL queries and poll asynchronous jobs until completion or failure.
- Retrieve result sets in chunks and do not assume a single response contains all data.
- Capture search job IDs, request IDs, source identifiers, and HEC response details.
Objective
Convert Splunk events, search results, and alert payloads into a canonical model or transform source records into Splunk event envelopes.
Instructions in Martini
- Normalize timestamps, host identifiers, source values, sourcetypes, indexes, and correlation identifiers.
- Map JSON, XML, or CSV search results to the downstream application's data model.
- Build HEC payloads with required event and metadata fields.
- Version transformations when source schemas, field extractions, or sourcetypes change.
Objective
Apply business and safety rules before writing to Splunk or a downstream application.
Instructions in Martini
- Validate index routing, SPL inputs, severity mappings, and required identifiers.
- Escape or otherwise constrain untrusted values used in SPL.
- Use stable alert, event, search-result, or source correlation identifiers for idempotency.
- Apply filtering, enrichment, and routing rules before downstream creation or update operations.
Objective
Submit HEC events, call Splunk REST resources, or write transformed results to applications, files, messaging systems, or SQL databases.
Instructions in Martini
- Send HEC data in bounded batches appropriate for deployment capacity.
- Create or update downstream objects only after validation and enrichment succeed.
- Use durable checkpoints and advance them only after successful target writes.
- Separate accepted, rejected, and partially processed items for reconciliation.
Common Splunk data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Events | Timestamped machine data indexed and searched for observability, security, and operational analysis. | ServiceNow, databases, data warehouses, PagerDuty, and reporting platforms | Martini normalizes timestamps and metadata, maps source payloads into HEC event envelopes, batches submissions, and handles rejected or retried events. |
| Indexes | Logical storage locations used to separate events by source, environment, access policy, or retention strategy. | Operational applications, reporting databases, and downstream analytics workflows | Martini uses configured index values when submitting events and validates routing rules so data is not written to an unintended index. |
| Search jobs | Asynchronous execution containers for SPL searches and large result sets. | ServiceNow, Salesforce, Jira, SQL databases, files, and messaging systems | Martini creates jobs, polls status, handles timeout and failure states, retrieves results in chunks, and stores durable synchronization checkpoints. |
| Saved searches | Reusable SPL searches that support reporting, alerting, and scheduled processing. | Martini APIs, notification workflows, incident systems, and reporting stores | Martini can invoke documented REST resources for saved searches, retrieve related results, and route outputs through reusable workflows. |
| Alerts | Search conditions that trigger actions or notifications for operational and security scenarios. | ServiceNow, Jira, PagerDuty, email services, and Martini APIs | Martini can receive selected webhook-style alert actions, validate identifiers and severity, apply routing rules, and create or update downstream objects idempotently. |
| Data inputs | Configured ingestion sources, including HEC inputs, monitoring inputs, and other platform-specific sources. | Application platforms, cloud services, Kubernetes, databases, and file sources | Martini can submit data through supported HTTP ingestion endpoints and can orchestrate source retrieval, normalization, validation, and batching. |
Authentication and security considerations
Authentication and least privilege
Splunk integrations may use bearer tokens, HEC tokens, Basic Authentication, or session keys depending on the endpoint and deployment. Use the method supported by the target Splunk environment and prefer token-based service access where appropriate.
- Store Splunk and HEC tokens, credentials, and certificates in protected Martini secrets or environment configuration.
- Use separate credentials for development, testing, and production.
- Apply Splunk roles and capabilities that limit access to required indexes, searches, inputs, and REST resources.
- Use HTTPS, validate certificates, and account for custom CA, mutual TLS, or proxy requirements where applicable.
- Do not write authorization headers, tokens, or sensitive event payloads to workflow logs.
Operational considerations for Splunk integrations
Throughput and search execution
Splunk Cloud and self-managed deployments can differ in request, search, concurrency, ingestion, and administrative limits. HEC payload size and throughput also depend on deployment capacity. Use bounded searches, selected fields, controlled batches, and exponential backoff for throttling and transient failures.
Pagination and checkpoints
Large search results should be retrieved in manageable portions. Recurring workflows should use durable checkpoints based on a time window plus a tie-breaker, while accounting for late-arriving events and timestamp precision.
Idempotency and schema control
Alert actions and HTTP requests may be retried. Stable identifiers help prevent duplicate downstream actions, while consistent index, source, sourcetype, host, timestamp, and correlation conventions protect searches and field extractions when payload schemas change.
Deployment differences
Splunk Enterprise and Splunk Cloud Platform can differ in endpoint URLs, ports, network access, permissions, and available administrative operations. Confirm the deployment-specific access model before implementation and test with representative search and ingestion volumes.
Why use Martini instead of scripts or point-to-point integrations?
Orchestrate beyond a single API call
Scripts can call Splunk endpoints, but enterprise integrations often need authentication boundaries, scheduled execution, asynchronous search polling, enrichment, routing, durable checkpoints, retries, and downstream updates. Martini provides a maintainable workflow for coordinating these steps.
Centralize transformation and business rules
Martini can map HEC envelopes, SPL results, alert payloads, and downstream application models without embedding transformation logic separately in every script or point-to-point interface. Validation and routing rules remain visible and reusable.
Improve reliability and operations
Martini workflows can distinguish transient failures from permanent data errors, apply retry policies, preserve correlation identifiers, and support monitoring and troubleshooting. APIs can also provide controlled integration boundaries for Splunk alert actions and consuming applications.
Frequently asked questions
Splunk can integrate through its REST APIs, SPL search and result APIs, HTTP Event Collector for event ingestion, asynchronous search jobs, and selected alert actions that invoke HTTP or webhook-style endpoints. Martini can orchestrate these mechanisms with scheduled workflows, APIs, mapping, validation, and error handling.
Yes. No native Martini Splunk connector is documented in the supplied sources, but Martini can consume Splunk REST APIs, submit events through HEC, execute and poll SPL searches, and receive selected Splunk webhook-style alert requests through Martini APIs or workflows.
No. A dedicated Splunk connector is not required. Martini can use Splunk's confirmed native REST APIs, HEC HTTP endpoints, authentication methods, asynchronous search operations, and selected alert webhook actions.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Splunk. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Splunk, cloud infrastructure, or other third-party systems based on subscriptions, usage, and deployment model.
Use Splunk REST APIs for administrative, search, configuration, and resource operations, HEC for event ingestion, and asynchronous search jobs for large or long-running queries. Selected alert webhook actions are suitable for alert-driven workflows, but they should not be treated as a universal event stream.
Splunk can invoke an HTTP or webhook-style alert action for selected configured alert scenarios. Martini can expose a secured API endpoint or receive the request in a webhook-oriented workflow, but Splunk does not generally send a webhook for every indexed event.
Martini can schedule bounded SPL searches, create or export searches, poll asynchronous search jobs, retrieve results in chunks, map the results, and write them to downstream applications or databases. Durable checkpoints based on time and a tie-breaker help manage recurring synchronization and late-arriving events.
Martini can distinguish authentication, authorization, malformed SPL, invalid HEC payload, throttling, transient service, and permanent schema errors. Workflows can retry suitable network, 429, and 5xx failures with backoff, while stable event, alert, search-result, or source identifiers support idempotency and duplicate prevention.
Related Martini documentation
Workflows
Data
Build a maintainable Splunk integration with Martini
Use Martini to connect Splunk REST APIs, HEC ingestion, SPL searches, and selected alert actions with enterprise applications through secure, observable workflows.