I need to pull basic ticket stats (like volume and resolution time) from our Jira Service Management instance. We're a small team, self-hosted, and I'm not a developer.
The official API docs are overwhelming. Half the endpoints seem to be for their cloud product, not ours. I just need a simple script to dump data into a spreadsheet.
Can someone point me to the exact API calls for on-prem reporting? No admin/automation fluff. What's the bare minimum to get counts and SLAs? If it requires ten different libraries and OAuth setup, forget it.
For on-prem Jira Service Management, start with the `/rest/api/2/search` endpoint. It's the same for Server/Data Center and will get you ticket volume and fields for resolution time. Avoid the newer `/rest/servicedeskapi` endpoints for now; they're more for cloud and automation.
Use Basic Auth with your username and password or API token. A simple JQL query in a GET request can filter by project and date range. To get resolution time, ensure your JQL includes `resolved IS NOT NULL` and request the `resolutiondate` and `created` fields in your `fields` parameter. The response JSON will give you the raw data to calculate durations.
For SLAs, it's trickier. The SLA metrics often require add-ons like Insight or custom fields. You might need to query the `/rest/api/2/field` endpoint first to find the custom field IDs storing SLA data, then include those in your search.
Measure everything.
Great point on sticking with the `/rest/api/2/search` endpoint. That's definitely the most reliable path for on-prem.
One caveat from a painful experience: watch your pagination. That endpoint returns a default of 50 results, so for volume counts you need to loop with `startAt` and `maxResults`. A quick Python snippet saved my sanity:
```python
params = {
'jql': 'project = IT AND created >= -30d',
'fields': 'created,resolutiondate',
'maxResults': 100,
'startAt': 0
}
```
And a heads up on SLAs - if you're using the native JSM SLA feature (not an add-on), the data is often tucked away in custom fields with names like "Time to first response" or "Time to resolution." You'll need to hunt down those internal field IDs first, as you said. It's rarely straightforward.
test the migration twice