ServiceNow → JSM integration via Jira Spoke — auth approaches?

[Kent G]

Hi All!

We're integrating ServiceNow with Jira Service Management using the Jira Spoke to create tickets in JSM from ServiceNow, and we're hitting authentication issues that I'm hoping others have solved.

Instance details:

• Jira/JSM Cloud, Premium plan
• Multiple JSM spaces/projects in scope for ticket creation from ServiceNow
• Integration is bi-directional (ServiceNow ↔ JSM)

What we've tried:

1. Atlassian Service Account (API token) — Authenticates fine, but the API call (via ServiceNow Spoke) doesn't return any data. Calls appear to succeed but the payload returns empty, so we can't get ticket creation/updates working reliably this way. We believe this may be due to the fact that Jira global permissions cannot be assigned to Atlassian Service Accounts because using a real user's Jira account works just fine, but is not viable long-term.
2. AD Service Account — This works initially, but the session eventually fails due to a timeout. As far as we can tell, this isn't an AD policy issue (the AD account itself doesn't expire) — it looks like a Jira/Atlassian session-length setting that's killing the connection after a set period, which then requires manual re-authentication to restore the integration.

What we're looking for:

• Has anyone gotten the Jira Spoke working reliably with an Atlassian Service Account, and if so, did you need to configure anything specific (scopes, permissions, API token type) to get data back?
• For those using an AD/service account approach — how are you avoiding or managing the session timeout? Is there a specific Jira setting you adjusted, or are you handling token refresh/re-auth automatically on the ServiceNow side?
• Is anyone using a different auth method entirely (OAuth 2.0 app, Connect/Forge app, middleware layer) to avoid this problem altogether?

Any insight into what's worked (or specifically failed) for your instance would be a huge help. Happy to share more detail on our config if it helps others troubleshoot similar issues.

[Gabriela - LeanZero]

Hi @Kent G, Viswanathan is right about the gateway URL and right to point at group and project permissions. I'd start on the permissions side, since the belief in your post is the part to drop.

I reproduced your shape on a test site this morning. On a JSM space where mypermissions reported Browse Projects, Create Issues, Edit Issues and Transition Issues all true and Service Space Agent false, a search for that project key came back 200 with an empty issues array, and a work item I could pull through /rest/servicedeskapi/request/KEY answered 404 through /rest/api/3/issue/KEY. Same credential, same minute, and nothing in either response says why.

Atlassian's token doc says "Service accounts are subject to the same permission and scope requirements as user accounts", and its own troubleshooting says that when a normal user works and the service account doesn't, compare their group memberships and product access. So check what product access that account holds on JSM and whether it's in a role on each space. Transitions need both: "In service projects, users are required to have a JSM license and the Service Project Agent's permission to perform an issue transition." One caution before you build on that, the service-account doc talks about granting access to Jira or Confluence and doesn't mention agent seats at all, so confirm in admin what you can actually assign it.

To separate that from the URL, run one call twice with the same token, once against your site host and once against https://api.atlassian.com/ex/jira/ plus your Cloud ID. Projects back on the gateway and an empty array on the site host is the URL, and Atlassian's KB says service accounts can only create scoped API tokens, which is what the gateway rule is about. The same result on both hosts puts you back on permissions. Not /rest/api/3/search for this, that one's removed and answers 410 before auth is looked at.

The AD one depends on which option it's on. If it's OAuth, Refresh Token URL sits on the application registry record under All, System OAuth, Application Registry, and ServiceNow hides that field in the form layout until you add it. If it's populated and you still lose the connection weeks in, look at whether ServiceNow is storing the rotated token, since "every new refresh token returned invalidates the refresh token used to get the new access token" and the leeway for replaying an old one is ten minutes. The ninety-day inactivity clock won't be it unless the integration goes quiet for months, and none of it is a Jira session length.

On a different method entirely, these accounts can also hold an OAuth 2.0 credential, client credentials against auth.atlassian.com/oauth/token with a sixty-minute access token and nothing to re-authenticate by hand. The spoke's current page documents no such grant though, so the ServiceNow KB you were pointed at is where that one settles.

Which of the setup options did you use? I ran the permission side on my own test site but haven't driven the spoke, so I can't promise every action survives the /ex/jira prefix, and I haven't confirmed what JSM access a service account can be given.

[Kent G]

Thanks for this info! I work only on the Jira side and am working with a colleague who has access to the ServiceNow side, so coordinating our efforts may take a couple days. I will reply back when I have results. Thanks!

[Viswanathan Ramachandran]

Hi @Kent G 

The primary reason calls return empty payloads comes down to URL endpoint routing and scoped token permissions. 

1. Empty Payloads: Service accounts use Scoped API Tokens, which require routing through Atlassian's accessible resources URL [https://<api.atlassian.com>/ex/jira]  instead of your standard [https://<yours>.atlassian.net] domain. Calling the atlassian.net domain directly with scoped tokens usually returns an HTTP 200 with an empty payload rather than a 401 error. Make sure mandatory scopes are granted and the service account is added to a Jira group with explicit project permissions (Browse Projects, Edit Issues).

2. AD Account (Session Timeouts): Human/AD accounts linked via 3-legged OAuth (Authorisation Code) rely on refresh tokens with fixed lifecycles. If ServiceNow isn't automatically managing the token refresh background task, the session drops.

What works best?

• Option A: Use OAuth 2.0 Client Credentials (2LO) in ServiceNow's OAuth registry to enable true machine-to-machine auth that doesn't expire with user sessions.

• Option B: Use standard API tokens with a dedicated service user account (Atlassian ID) assigned to a service group in Jira, rather than an AD-synced user account or scoped service account.

If it helps, you can quickly try these using

1. Test the Endpoint URL: Run a query using the Atlassian Service Account's scoped API token against both https://<yours>.atlassian.net/rest/api/3/search and https://<api.atlassian.com>/jira/rest/api/3/search to confirm if endpoint structure is the culprit behind the empty payloads.
2. Switch Grant Type: If stickier auth is needed for the AD approach, update the oauth_entity_profile in ServiceNow to use Client Credentials. See https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB2775690

[Kent G]

This is helpful and I appreciate the quick response. I will reply back with results once I get a chance to try these things. Thanks!