Is there an API to get a close date of an issue.?

[Rupal Khare]

I want to track and log the date on which issues are being closed, Is there any API i can use?

[Andrey Tetyuev]

I know only one suitable solution: you should go through change-log (i.e. history) of each Issue, then within list of changes check only the items related to the Issue- state-change and get the date/time of this change. It's not only about "Closed" state - you might get further KPIs in this way (e.g. how long Issue was in each state - as cumulative time, as longest, what was the first reaction time, etc.)
If you only need the latest Issue-closing datetime by closed Issues (because the Issue might get re-opened after first closing), I would recommend following steps:
1) Search/filter for Issues which are currently in "Closed" state
2) Check the changes-history of each Issue from latest to earliest and catch the change to "Closed" state -> this is the required value of datetime, when certain Issue was closed.
Some additional hints:
You might need to limit count of Issues returned at once by REST API (history could be huge) and expand the changelog, e.g.:

https://YOUR_JIRA_SITE/rest/api/2/search/?jql=project=YOUR_PROJECT_NAME%20AND%20status%20in%20(Closed)&expand=changelog&fields=key,resolutiondate,status&maxResults=50

[Ronald Vallenduuk]

There is no direct closed date field on the issue, but you can find it in the issue history or changelog as described here:

https://community.atlassian.com/t5/Jira-questions/Issue-history-through-REST-API/qaq-p/503830

[Petter Gonçalves]

Hello Rupal,

The closure date of an issue would be registered in the resolution date field, considering that a resolution is set once the issue is closed.

That been said, the following query should return the Resolution date of a specific issue:

https://yourdomain.atlassian.net/rest/api/3/issue/issuekey?fields=resolutiondate

Where the issuekey parameter of the URL must be replaced with the issue key you want to return.

For more information about this, check the documentation below:

- Get Issue - REST API

Let me know if you still have any questions.

[Ronald Vallenduuk]

This is based on the (false) assumption 'that a resolution is set once the issue is closed'.

In our workflows resolution is set after QA, the issue doesn't get closed until after UAT.

See below for correct answer.

[Petter Gonçalves]

Hello @Ronald Vallenduuk

Thank you for your feedback.

Actually, the resolution field was designed to be added once the issue is completely closed/resolved. In fact, the goal of using the resolution field would be to specify the reason an issue is closed and removes the need of having multiple statuses with the purpose of stating why the issue is closed, as you can see in the KB below:

Best practices on using the "Resolution" field 

Although you can add the resolution before the "Done" status of your workflow, your issues will be considered closed in Jira application, so several reports and system filters will not work as expected (As you can see in this example). 

Basically, your issues will not be tracked and the progress/estimation of your (still) open issues will not be considered, causing unexpected behaviors if you want to use the full functionality of Jira Cloud as it was designed to work.

Please, take a look at the mentioned KB and let us know if you have any questions.

[Andrey Tetyuev]

@Petter Gonçalves : actually it depends on WorkFlow used in the project. The resolutiondate being set when the Resolution-field get filled. But after this step there might be additional workflow-step and the Issue get closed first after that additional step.
Example: project service-team resolves Issue with some solution-text, then the Issue goes to "customer" and being moved to the state "Final Check @Customer". As final confirmation that the Issue was really resolved with given solution - the customer closes the Issue. There might be some days/weeks/months between the Issue get resolved from service-team point of view (i.e. the resolution field & date are set) and real closing of the Issue. I knew many projects, where such JIRA workflow was used.