Last verified · 1 day ago
Jira Cloud's API will happily create the ticket. Splunk's built-in webhook alert action cannot be the thing that calls it, because it has no documented way to send a credential. Every working version of this integration is an add-on or a custom alert action sitting between the two, and that is code someone has to own.
Splunk → Jira Cloud Partial
A quarter
How long until ticket volume is something an analyst can live with.
Wiring the connection is an afternoon. The quarter is the tuning, deciding what earns a ticket. It is the slowest integration on this site.
Erick Ingleby, not a vendor figure
This is the integration people assume is a checkbox and discover is a small project. Both halves are individually excellent. Splunk fires alerts reliably and documents an extension point for outbound actions. Jira Cloud has a published OpenAPI document and a create-issue endpoint that does exactly what it says. The gap is precisely in the middle: Splunk's one built-in HTTP action posts an unauthenticated JSON body containing a single result row, and Jira will not accept that. What you need in between is either an add-on from Splunkbase, which means taking on someone else's release cadence and credential handling, or a custom alert action of your own, which means owning Python inside a Splunk app forever. Neither is hard. Both are more than the afternoon people budget for it.
In my own words
Do not send every notable event to Jira.
You will create so many cases that Jira becomes unmanageable, and you pay for it twice: once on the Jira bill, and once in your analysts being unable to find anything meaningful in there. Put something in front of it. Risk based alerting, or any threshold that decides what actually earns a ticket.
Which means: get Enterprise Security. This is exactly what it is for. If you are doing DevOps or something adjacent you are probably fine without it, but for security in any real sense, buy it. Yes, you could build it yourself. Are you honestly going to spend fifteen years rebuilding what proven security practitioners already built? Do not fool yourself. Spend the money.
Deciding what earns a ticket is the integration. The connection is the easy part.
Erick Ingleby
A single POST creates a Jira issue. It needs the Browse projects and Create issues project permissions, or the write:jira-work scope on an OAuth 2.0 app. It can apply a transition at creation time and set issue properties in the same call, so a ticket can arrive already in the right workflow state rather than landing in the default column.
POST /rest/api/3/issue Bulk create takes up to 50 issues in one request. That is genuinely useful for a scheduled search that returns many rows, and it is also a hard ceiling, so anything larger has to be chunked by whatever code you write.
POST /rest/api/3/issue/bulk The loop can be closed both ways. Comment, update and transition endpoints all exist, and a GET on the transitions path tells you which transitions are currently available for that issue rather than making you hard-code workflow IDs that will change under you.
POST /rest/api/3/issue/{issueIdOrKey}/transitions Basic auth with an Atlassian account email address and an API token is documented, works, and survives two-factor authentication or SAML on the Atlassian organization. For a first working version this is the fastest route. Read the caveat below before you standardize on it.
Splunk documents custom alert actions as a supported thing app developers build, user-configurable from the alert screen once installed. This is the correct shape for a Jira integration and it is the shape every working Splunkbase Jira add-on uses.
Splunk's webhook alert action is documented as a URL plus a fixed JSON body. The page describes no field for an Authorization header, a bearer token or basic auth credentials, and Jira will reject an anonymous POST to the issue endpoint. Splunk does not say the action cannot authenticate, only that no such field is documented, so people reach for a credential in the URL or an authenticating proxy in front of Jira. Either way something has to sit in the middle, which is why the integration is not a checkbox.
The payload contains the first result row of the triggering search, plus the search ID, a results link, the owner and the app. If your correlation search returns forty hosts, the callback knows about one of them. Even with an authenticating proxy in front, the webhook is the wrong source of truth for ticket content.
On the v3 API the description and environment fields, and every multi-line custom field, take Atlassian Document Format rather than plain text. Single line textfield custom fields take a string and do not handle ADF, so the two rules are opposites and both apply in the same payload. This is the most common reason a first attempt at issue creation returns 400.
Jira Cloud enforces a points-based hourly quota, a per-second burst limit with its own token bucket per endpoint per tenant, and a per-issue write limit, simultaneously. You can be comfortably inside your hourly quota and still get a 429 for hammering one endpoint, or for updating one noisy issue too often. The RateLimit-Reason header tells you which one you hit: jira-quota-global-based or jira-quota-tenant-based, jira-burst-based, or jira-per-issue-on-write. Handle all three or your alert storm will lose tickets.
The burst limit is per tenant and per endpoint and is explicitly independent of how many users you have. Defaults are 100 requests per second for GET and POST and 50 for PUT and DELETE, with some endpoints carrying their own custom bucket. Growing the Jira license does not make the integration faster.
Atlassian documents basic auth with an API token, then states that apps which collect API tokens, or instruct customers to create individual 3LO apps, do not comply with its security requirements for cloud apps, and asks integrators to move customers away from both. A shared service-account API token in a Splunk add-on is exactly the pattern being discouraged. It works today. Do not build a product on it.
Atlassian's rate limiting page states that enforcement of the new points-based and tiered quota limits for Jira and Confluence Cloud apps begins on 2 March 2026, applying to Forge, Connect and OAuth 2.0 3LO apps, and that API token-based traffic is not affected and stays on the existing burst limits. If your integration authenticates as an OAuth app, its effective budget is not the one it was built against.
The whole documented surface of Splunk's built-in webhook. A URL field, the JSON payload shown in full, and the allow list requirement from Splunk Enterprise 9.0 and Splunk Cloud Platform 8.2203. No authentication field appears anywhere on the page.
VENDOR DOC · Checked
Confirms the extension point exists and that it is something app developers build, not something an admin configures on an alert.
VENDOR DOC · Checked
Atlassian's machine-readable spec. Source of every endpoint and permission on this page, the 50 issue bulk limit, the write:jira-work scope and the Atlassian Document Format rules on description and custom fields.
VENDOR DOC · Checked
Source of the three simultaneous limits, the RateLimit-Reason values, the default per-second figures by HTTP method, the statement that burst capacity does not scale with user count, and the 2 March 2026 enforcement notice.
VENDOR DOC · Checked
Source of the working email plus API token pattern, the deprecation of password auth, and Atlassian's notice that collecting API tokens or asking customers to create their own 3LO apps does not comply with its cloud app security requirements.
VENDOR DOC · Checked