REST API Calls for Request

[Sivarama Krishna K]

How to Know the list of REST API Calls triggered on each Search or view issue.

/rest/api/latest/issue/PROJ-1234

or

rest/api/latest/search?jql=filter=10015

[Nicketa]

Option 1: Log REST Calls to Console in Real Time

Paste this snippet into your console. It intercepts all outbound fetch and XHR network requests and prints only Jira REST API endpoints (/rest/api/) as they trigger:

(function() {
console.log("%c [Jira API Monitor Started]", "color: #0052CC; font-weight: bold; font-size: 14px;");

// Intercept Fetch Requests
const originalFetch = window.fetch;
window.fetch = async function(...args) {
const url = typeof args[0] === 'string' ? args[0] : args[0]?.url;
if (url && url.includes('/rest/')) {
console.log(`%c[FETCH %s] %c${url}`, "color: #00875A; font-weight: bold;", args[1]?.method || 'GET');
}
return originalFetch.apply(this, args);
};

// Intercept XHR (AJAX) Requests
const originalOpen = XMLHttpRequest.prototype.open;
XMLHttpRequest.prototype.open = function(method, url) {
if (url && url.includes('/rest/')) {
console.log(`%c[XHR %s] %c${url}`, "color: #DE350B; font-weight: bold;", method);
}
return originalOpen.apply(this, arguments);
};
})();

Open Jira (e.g., your issue or search page). Press F12 and click Console. Paste the code above and hit Enter.

Perform your search or load the issue—all incoming/outgoing REST API URLs will stream in the console output.

Option 2: Terminal / Linux Console (curl Inspection)

You can query the Jira REST API directly using curl to see the payload structure returned for issue views and searches:

View Issue API Response:

 curl -u "user@domain.com:api_token" \
-H "Accept: application/json" \
"https://your-domain.atlassian.net/rest/api/2/issue/PROJ-1234"

Search / JQL API Response:

curl -u "user@domain.com:api_token" \
-H "Accept: application/json" \
"https://your-domain.atlassian.net/rest/api/2/search?jql=filter=10015"
 

[Mohammad Mahyar ahmadi]

Hi Sivarama,

There's no published list - it changes between Jira versions and with whatever apps you have installed, so you have to observe it.

Quickest way is the browser. F12, Network tab, tick "Disable cache", filter to Fetch/XHR, then hard-reload the issue. No server access needed, but it only shows what the browser asks for - anything Jira calls server-side never appears there.

The complete picture is in the Tomcat access log. The AccessLogValve is defined in your server.xml and writes to $JIRA_INSTALL/logs/access_log.yyyy-MM-dd. Worth checking it's actually enabled on your instance rather than assuming it is. 

Filtering that log by timestamp is fiddly, so I mark the line count first and then read only what came after:

    LOG=$JIRA_INSTALL/logs/access_log.$(date +%F)

    BEFORE=$(wc -l < $LOG)

    # hard-reload the issue in your browser and let it finish

    tail -n +$((BEFORE+1)) $LOG | grep rest | sort | uniq -c | sort -rn

Two things in that log format cost me time, so worth passing on.

A dash means an empty value, not part of the path. If a line looks like it ends in "resources-", that's the path with an empty query string, nothing more.

And the unit of %D depends on your Tomcat version. The Tomcat docs say "Time taken to process the request in millis. Note: In httpd %D is microseconds. Behaviour will be aligned to httpd in Tomcat 10 onwards." So Tomcat 9 gives you milliseconds and Tomcat 10 and later gives you microseconds. Mine runs Tomcat 10.1.55 and I spent a few minutes convinced the box was a thousand times slower than it actually is.

One thing that surprised me doing this on my own instance: of roughly 60 distinct endpoints hit by opening a single issue, only about 15 were Jira core. The rest were marketplace apps, each polling their own resource every time an issue is opened. If you're chasing performance rather than curiosity, that's usually where it lands.

Last thing - most of what you'll see is internal and changes between versions without notice. Only the documented API is safe to build against, and prefer version 2 over "latest" in anything you write yourself, since "latest" quietly moves under you at the next upgrade.

Happy to paste the full endpoint list I captured if that would help.