Splunk’s New SDK Explained for Experienced Developers 

By David Burns, Team Lead, Automation Engineering

A Faster, Cleaner Way to Build SOAR Apps 

For seasoned developers working with Splunk SOAR, app development has historically not been exactly smooth: brittle JSON metadata, limited validation, UI-dependent testing, and packaging workflows that felt increasingly out of step with modern software engineering practices. The traditional Phantom-era model got the job done, but those familiar pain points… 

Splunk’s new SOAR SDK represents a purposeful evolution rather than a radical reinvention. It does not change the traditional template pattern that we know and love, or how apps ultimately behave inside SOAR. Instead, it modernizes how apps are built, shifting development left with better tooling, stronger guarantees, and workflows that align with how most engineering teams already operate. 

For developers who already know the old way well, the value of the SDK becomes obvious once you frame it correctly: not about learning SOAR again but finally treating SOAR apps like real software projects. 

What the New SOAR SDK Is (and Is Not) 

At a high level, the new SDK provides: 

  • A CLI-driven development workflow 
  • Schema-backed definitions for apps, actions, and assets 
  • Local validation and linting 
  • A standardized, opinionated project structure 

What it does not do: 

  • Break or deprecate existing apps 
  • Change how SOAR executes actions 
  • Replace Python connectors with a new runtime 
  • Eliminate the need to understand SOAR internals 

The SDK sits above the existing app model. You still deploy a standard SOAR app package. The difference is that you arrive at that package through a repeatable, validated, developer-friendly process. 

Traditional SOAR App Development: A Quick Reality Check 

Experienced developers will recognize this workflow immediately: 

  1. Generate an app skeleton. 
  1. Manually edit app and actions in the json, and related metadata 
  1. Write Python connector logic 
  1. Zip the app 
  1. Upload it into SOAR 
  1. Discover missing fields, typos, or schema errors at runtime 
  1. Repeat 

This model works, but it places validation very late in the cycle. Many issues only surface once the app is installed, actions are executed, or assets are configured in the UI. Over time, as apps grow more complex, metadata drift and undocumented assumptions become common—especially in teams with multiple developers. 

The new SDK directly addresses these friction points. 

Key Differences Between the Old Model and the New SDK 

Below is a side-by-side breakdown of what has materially changed, focusing on areas that matter to experienced developers. 

1. Project Structure and Organization 

  • Old approach 
  • Flat or semi-structured directories 
  • Metadata and logic intermingled 
  • Conventions enforced socially rather than technically 
  • New SDK 
  • Clearly defined project layout 
  • Explicit separation of metadata, connector logic, and configuration 
  • SDK-generated scaffolding that enforces consistency 

Why it matters: 
Larger teams benefit immediately. New contributors can understand an app’s layout without tribal knowledge, and long-lived apps remain readable years later. 

2. Schema-Driven Definitions 

  • Old approach 
  • JSON files edited by hand 
  • Minimal validation before deployment 
  • Errors often discovered only after installation 
  • New SDK 
  • Strongly defined schemas for apps, actions, and assets 
  • Local validation catches missing fields, invalid types, and structural errors 
  • Clear, actionable error messages 

Why it matters: 
This is arguably the biggest improvement. Schema enforcement eliminates an entire class of runtime failures that previously required UI testing to uncover. 

3. CLI-First Development Workflow 

  • Old approach 
  • App creation and iteration tightly coupled to the SOAR UI 
  • Manual packaging steps 
  • Limited automation support 
  • New SDK 
  • CLI commands for project creation, validation, and packaging 
  • Repeatable build steps 
  • Natural fit for automation and scripting 

Why it matters: 
The SDK finally makes SOAR app development compatible with CI/CD pipelines, code reviews, and automated quality gates, something many teams previously bolted on manually. 

4. Local Validation and Early Feedback 

  • Old approach 
  • Validation happens late 
  • Testing often requires a live SOAR instance 
  • Debugging involves repeated upload/install cycles 
  • New SDK 
  • Local validation before packaging 
  • Structural and schema errors caught immediately 
  • Faster feedback loops 

Why it matters: 
Developers spend less time context-switching into the SOAR UI and more time writing reliable code. This is especially valuable when working on shared libraries or foundational connectors. 

5. Maintainability at Scale 

  • Old approach 
  • Apps evolve organically 
  • Metadata inconsistencies accumulate 
  • Harder to enforce standards across teams 
  • New SDK 
  • Opinionated structure encourages uniformity 
  • Easier to compare apps and reuse patterns 
  • Better foundation for internal frameworks or shared tooling 

Why it matters: 
This alone can justify adopting the SDK for new development and maintenance of multiple SOAR apps 

What Has Not Changed 

It is equally important to understand what remains the same: 

  • Apps still run inside SOAR exactly as before 
  • Connectors still written in Python 
  • Actions, assets, and playbooks behave the same way 
  • Existing apps continue to work without modification 

This is not a breaking change but an evolution. There is no forced migration timeline. 

Practical Implications for Existing App Portfolios 

For teams with established SOAR apps in production, the SDK introduces a strategic decision rather than an immediate requirement. 

You likely do not need to: 

  • Rewrite stable, low-churn apps 
  • Migrate legacy apps solely for parity 
  • Change existing deployment processes overnight 

You should strongly consider the SDK when: 

  • Building new apps 
  • Performing major refactors 
  • Standardizing development across teams 
  • Introducing CI/CD or automated testing 
  • Onboarding new developers 

Many teams will find a hybrid approach effective: legacy apps remain untouched, while all new development uses the SDK going forward. 

Why This Matters Long-Term 

From a platform perspective, the SDK signals Splunk’s intent to treat SOAR app development as a first-class engineering discipline rather than a niche, UI-centric workflow. 

For developers, this brings several long-term benefits: 

  • Fewer production surprises 
  • Clearer ownership boundaries 
  • Easier collaboration 
  • Better alignment with modern DevOps practices 

In other words, the SDK reduces operational risk without changing the mental model of how SOAR works. 

Final Takeaway 

If you are already comfortable building SOAR apps the traditional way, the new SDK does not ask you to relearn SOAR. It allows you to stop compensating for tooling gaps in the traditional method of development. 

The core value proposition is simple: the same apps, built with far better guarantees. 

For experienced developers, adoption becomes less a question of if but when. 

Ready to accelerate your Splunk SOAR development and streamline security automation projects? Explore professional Splunk services and expert support from TekStream.

About the Author

David Burns is a security engineer with experience working with Splunk Enterprise Security and Splunk SOAR (formerly Phantom) for a large fortune 200 bank. Before that he was a System Security Engineer working on the automation of security testing of OT systems.

He brings his 20+ years programming background to use SDLC in rapid development of playbooks, custom functions, and more leading to modularity, re-use in design, and better long-term maintenance. For example, creating deeper integration for escalation through Slack and creating EDL management for multiple clients.


At TekStream, he developed the slack escalation methodology that notifies customers of events that need their attention as well as a way of process for generating and updating EDLs within Splunk.