Bulk-fetch many Jira Cloud issues and their changelogs efficiently instead of looping single-issue GETs

Documented steps

1. For a known set of issue keys/IDs use POST /rest/api/3/issue/bulkfetch with body {"issueIdsOrKeys":["ABC-1","ABC-2"],"fields":["summary","status","assignee"]}. Up to 100 issues per request.
2. Always pass 'fields' explicitly. The bulkfetch default is *navigable, which is NOT all fields — a common source of 'the field is missing' bugs when migrating from single-issue GET (which defaults to all fields).
3. Read the response carefully: {"issues":[...],"issueErrors":[...]}. Issues you lack browse permission for, or that do not exist, are silently OMITTED from both arrays. Never assume issues.length + issueErrors.length equals what you requested — diff against your input list.
4. Results come back ordered ascending by issue id, not in the order you supplied. Re-key the response by issue key if order matters.
5. You may mix IDs and keys in issueIdsOrKeys; Jira resolves keys case-insensitively and follows moved issues inline without returning a redirect.
6. For history on one issue: GET /rest/api/3/issue/{issueIdOrKey}/changelog?startAt=0&maxResults=100, returned oldest first.
7. For history across many issues: POST /rest/api/3/changelog/bulkfetch — up to 1000 issues, filterable by up to 10 field IDs, paginated and sorted oldest first. This is the right tool for audit exports and cycle-time analytics.
8. Do not use expand=changelog on bulkfetch for full history: it truncates at 40 changelog entries per issue.
9. If you are discovering the issue set rather than starting from known keys, run /rest/api/3/search/jql first with fields=['id'] to page out the IDs, then bulkfetch in batches of 100.