project/list resource: project

When to Use

• Project key validation: Before processing a user-supplied project key in a workflow, call project/list to confirm the project exists and the service account has access to it. This prevents downstream errors from invalid project keys.
• Dynamic project selection: A workflow receives project selection input from a web form. Rather than hardcoding project keys, it calls project/list to build the dropdown options dynamically from the actual Jira instance.
• Cross-project reporting: A monthly metrics workflow lists all projects, filters to those matching a naming pattern (e.g. all projects with type "software"), and runs issue queries on each to aggregate cross-project KPIs into a management report.
• New team onboarding: When a new team is onboarded, an onboarding workflow calls project/list to identify all existing software projects and checks whether the new team's project already exists before creating a new one.
• Health check audit: A governance workflow lists all projects and verifies each has a designated project lead (non-null lead field). Projects without a lead are flagged for assignment in a governance report.

Configuration

Connection

Operation Fields

Sample Configuration

{
  "resource": "project",
  "operation": "list",
  "Host": "https://acmecorp.atlassian.net",
  "Email": "automation@acmecorp.com",
  "ApiToken": "{{ $credentials.jiraApiToken }}",
  "Expand": "description,lead"
}

Validation Errors

Output Fields

Sample Output

{
  "status": "success",
  "projects": [
    {
      "key": "OPS",
      "name": "Operations",
      "type": "software",
      "lead": "Sarah Chen",
      "description": "Production operations and incident management"
    },
    {
      "key": "DEV",
      "name": "Development",
      "type": "software",
      "lead": "Marcus Webb",
      "description": "Core product engineering"
    },
    {
      "key": "SUPPORT",
      "name": "Customer Support",
      "type": "service_desk",
      "lead": "Priya Nair",
      "description": "Customer-facing support tickets"
    }
  ],
  "total": 3,
  "resource": "project",
  "operation": "list"
}

Expression Reference

Node Policies & GuardRails

• Returns only accessible projects: The API returns only projects the authenticated user has Browse Projects permission for. This may not be all projects on the instance — admin accounts see more projects than standard users.
• Cache for repeated use: Project list changes rarely. If calling project/list multiple times in a workflow run for validation, cache the result in a VariableAssignment node rather than making repeated API calls.
• Rate limit awareness: This call counts against the Jira rate limit. On instances with many projects (50+), the response may be large. Consider calling only when validation is needed, not for every issue operation.

Workflow Examples

Example 1 — Validate Project Key Before Issue Creation

// Step 1: project/list
{
  "resource": "project",
  "operation": "list"
}
// Step 2: IfCondition — validate that requested project key exists
// Condition: $output.listProjects.projects.some(p => p.key === $json.requestedProject)
// Step 3 (if valid): issue/create
// Step 3 (if invalid): StopWorkflow with error message "Project not found"

Example 2 — Cross-Project Issue Count Report

// Step 1: project/list
// Step 2: Loop over projects
// Step 3 per project: issue/getAll
{
  "Jql": "project = {{ $loopItem.key }} AND status != Done AND created >= -30d",
  "Limit": 1
}
// (Only fetching 1 result to get the total count efficiently)
// Step 4: MongoDB/insert — record { project: $loopItem.key, openIssues: $output.getAllIssues.total }