Context

When investigating sprints via the Jira Software Cloud REST API, we often need to know whether a sprint’s originBoardId points to a board that has been deleted or one that still exists but is permission‑restricted. This is important for automation, cleanup of orphaned sprints, and correct triage (fix permissions vs. accept historical deletion).

Current behaviour

• GET /rest/agile/1.0/sprint/{sprintId} returns an originBoardId.
• Calling GET /rest/agile/1.0/board/{originBoardId}{}:
• Returns 404 Not Found both when:
  • The board has been deleted.
  • The board still exists, but the caller lacks permission.
• There is currently no API‑level signal to distinguish these two states.

This ambiguity makes it difficult for those using the public API to tell whether they should:

• Troubleshoot permissions, or

• Treat the sprint as linked to a deleted/orphaned board and proceed with cleanup.

Suggested Improvement

Provide a way via the REST API to reliably distinguish deleted vs restricted boards. For example:

1. Differentiate via HTTP status codes
   1. Return 403 Forbidden when the board exists but the calling user does not have permission.
   2. Reserve 404 Not Found for boards that truly do not exist anymore.
2. Expose explicit board status
   1. Add an endpoint/parameter (admin‑only or app‑scoped) that returns metadata like:

{  "id": 252,  "status": "DELETED" // or "RESTRICTED" } 

Access to this information can be limited to site admins or apps with appropriate scopes to avoid leaking details to regular users.

Suggested workaround

Until the API can distinguish these states:

• Site admin verification:
  A site admin can try to access the board directly in the UI using the originBoardId. If a site admin also cannot access the board and no board record exists for that ID, it can be treated as deleted.

• Atlassian Support verification:
  You can raise a case with Atlassian Support. Support engineers can check internal data to confirm whether the board still exists or has been deleted.