How to filter out site settings linked to Team-Managed projects using Jira GET REST APIs

[gopal guna]

Hi team.

I'm currently working on an automation tool that will back up and restore all the site-level settings, projects, and issues on Jira Cloud. It covers backup and restores of all site-level settings (issue types, workflows, screens, fields, etc.), boards, filters, dashboards, projects and project metadata, and issues and their metadata. We only back up Company-Managed projects, not Team-Managed projects.

However, since we do not back up Team-Managed (Next-Gen) projects, during restore we observed failures for certain items (like boards, filters, and dashboard gadgets) that were originally linked to Team-Managed projects. As far as I understand, most site-level settings in Jira Cloud (like workflows, screens, issue type schemes, etc.) are global and not linked to Team-Managed projects.

However, there are some items that are created specifically for a Team-Managed project, such as:

• Boards created under a Team-Managed project
• Filters whose JQL references a Team-Managed project key
• Dashboards, Permission schemes, and Notification schemes that have permissions referencing a Team-Managed project

Since these items appear in the standard GET REST APIs (Boards API, Filters API, etc.), they look similar to items from Company-Managed projects even though they belong to Team-Managed ones.

My questions are:

1. Is there a reliable REST API way to detect if a project is Team-Managed or Company-Managed?
   I see the style field ("classic" vs "next-gen") in the /rest/api/3/project/{id} response — is this the recommended method?
2. Is there any official guideline or filter to determine which site-level settings belong to Team-Managed projects, so we can safely skip backing them up or restoring them?
   For example: in the GET response (e.g., GET /rest/api/3/dashboard), is there any filter to show only the settings linked to Company-Managed projects?
3. Are boards/filters created under Team-Managed projects (and dashboards/permission schemes/notification schemes that reference Team-Managed projects) expected to appear in the GET APIs? Or is there a way to differentiate them before attempting restore?

Any best practices or recommended approach from Atlassian for handling these scenarios would be really helpful.

Thanks in advance!