Jira API integration - 3 questions

[JeffByers]

We are developing an app where we collect data from a customer. once we have collected the data we are wanting to to create a service desk ticket on their behalf.

Question 1: We were going to use OAuth2 but in trying to use that method there appears to be a human interaction that is required to allow access to API call. Is there away to avoid this human interaction. We have not found any documentation to substantiate an alternate way using OAuth2.

Question 2: Since we could find a way to do this in OAuth2 we have looked into creating a jira service type account and create a personal token every 30 days to accomplish our needs. Is this path preferred or acceptable?

Question 3: When we create a customer for Service desk using the API you supply that endpoint Full Name and Email. There is no Password to send to the end point. When we create this user using the endpoint does the customer get an email to go change his password or will we have to adjust for that?

[ibuchanan]

@JeffByers

Question 1: We were going to use OAuth2 but in trying to use that method there appears to be a human interaction that is required to allow access to API call. Is there away to avoid this human interaction.

I confirm human interaction is required for the OAuth 2.0 authorization code flow (called 3LO in our docs) and that Jira supports no other OAuth grants. The client credentials flow is the generally accepted OAuth flow for system-to-system integration (no human interaction). Alas, it is still a feature request (please watch, vote, and comment).

@JeffByers

Question 2: Since we could find a way to do this in OAuth2 we have looked into creating a jira service type account and create a personal token every 30 days to accomplish our needs. Is this path preferred or acceptable?

Acceptable by Atlassian policy, but not preferred. Currently, API Tokens do not have expiration. The recommended solution would be to use Forge and specifically Forge Remote to handle secure comms between your system and Atlassian. Both will be short of “ideal” when considering your customer’s user experience, and your own developer experience. From what you’ve explained, OAuth 2.0 client credentials would be ideal, but it’s not available.

@JeffByers

Question 3: When we create a customer for Service desk using the API you supply that endpoint Full Name and Email. There is no Password to send to the end point. When we create this user using the endpoint does the customer get an email to go change his password or will we have to adjust for that?

The short answer is that your client should not facilitate password change. Indeed, I don’t know how it could, even if you wanted to. I don’t think any of that state is available through APIs.

I don’t know if new customers are always notified by email. But, the customer will be given the option to set a password when they try to login, for example, if your client raised a new request on their behalf.