$npx -y skills add pixee/pixee-cli --skill pixee-integrationList Pixee integrations to discover the id, type, and capabilities of each scanner integration registered with the org.
| 1 | # pixee integration |
| 2 | |
| 3 | > **PREREQUISITES:** Read `../pixee-shared/SKILL.md` for global flags, exit codes, and error |
| 4 | > handling, and `../pixee-auth/SKILL.md` if authentication needs to be configured. See |
| 5 | > `../pixee-scan/SKILL.md` for the `--integration-id` consumer this skill's `list` verb feeds. |
| 6 | |
| 7 | `pixee integration` enumerates the third-party scanner integrations registered with the Pixee |
| 8 | organization. Each integration is the org-side configuration that lets the platform attribute an |
| 9 | uploaded scan to a known source (GitHub App installation, GitLab CI token, Sonar host token, |
| 10 | etc.) and grants the platform any extra capabilities that integration exposes — pushing triage |
| 11 | verdicts back, polling for scans on a cadence, and so on. |
| 12 | |
| 13 | The discovery flow exists primarily so an agent calling `pixee scan create --integration-id <id>` |
| 14 | has a canonical way to look up the integration id without dropping to `pixee api`. |
| 15 | |
| 16 | ## pixee integration list |
| 17 | |
| 18 | ``` |
| 19 | pixee integration list |
| 20 | ``` |
| 21 | |
| 22 | List integrations registered with the org. Pagination is transparent: the CLI walks every page |
| 23 | in one call. |
| 24 | |
| 25 | Text output is tab-separated with columns `id`, `type`, `capabilities`. The `capabilities` |
| 26 | column is a JSON-array literal (e.g., `[]` for an integration with no extras, `["triage-push"]` |
| 27 | when the integration can push triage verdicts back to the source). JSON output is a flat array |
| 28 | of integration records with the HAL envelope stripped — each record carries `id`, `type`, |
| 29 | `capabilities`, and a `_links` object for HAL traversal. |
| 30 | |
| 31 | The default integration registered for each scanner type often uses the id pattern |
| 32 | `<type>-default` (e.g., `sonar-default`, `polaris-default`, `github-default`), but that is a |
| 33 | convention, not a contract. List the integrations and read the `id` rather than constructing it |
| 34 | by hand. |
| 35 | |
| 36 | The `type` discriminator names the scanner family (e.g., `sonar`, `polaris`, `gitlab`, |
| 37 | `appscan`). It is **not** identical to the `--tool` enum on `pixee scan create` — the latter |
| 38 | distinguishes scan kinds at a finer grain (e.g., `polaris_sast` vs `polaris_sca`, |
| 39 | `gitlab_sast` vs `gitlab_dependency_scanning`), while the integration `type` collapses to the |
| 40 | provider family. |
| 41 | |
| 42 | ## Examples |
| 43 | |
| 44 | ```bash |
| 45 | # List every integration registered with the org |
| 46 | pixee integration list |
| 47 | |
| 48 | # JSON shape for programmatic consumption |
| 49 | pixee integration list --json | jq '.[] | {id, type, capabilities}' |
| 50 | |
| 51 | # Find integrations that can push triage verdicts back to the source |
| 52 | pixee integration list --json | jq '.[] | select(.capabilities | index("triage-push"))' |
| 53 | |
| 54 | # Discover the sonar integration id and use it in a scan-create call |
| 55 | integration_id=$(pixee integration list --json \ |
| 56 | | jq -r '.[] | select(.type=="sonar") | .id' | head -n1) |
| 57 | pixee scan create pixee/pixee-platform \ |
| 58 | --tool sonar --integration-id "$integration_id" \ |
| 59 | --branch main --sha "$(git rev-parse HEAD)" |
| 60 | |
| 61 | # Walk to an integration's HAL self link rather than re-listing |
| 62 | href=$(pixee integration list --json | jq -r '.[] | select(.id=="polaris-default") | ._links.self.href') |
| 63 | pixee api "$href" |
| 64 | ``` |
| 65 | |
| 66 | ## Best practices |
| 67 | |
| 68 | - The integration id is stable across calls; cache it per-org rather than re-listing on every |
| 69 | invocation. Resolve it from `pixee integration list` rather than constructing a |
| 70 | `<type>-default` string by hand, since that pattern is a convention the platform can change. |
| 71 | - Filter by `type` when looking for a specific scanner family. The org may have multiple |
| 72 | integrations of the same type (different GitHub Apps, multiple GitLab tenants) and `type` |
| 73 | alone is not unique. |
| 74 | - Read `capabilities` before assuming an integration can do more than receive uploads. |
| 75 | `triage-push` is the load-bearing one today; treat the array as forward-compatible and check |
| 76 | for membership (`jq '.capabilities | index("...")'`) rather than equality. |
| 77 | - Don't conflate integration `type` with `pixee scan create --tool`. The mapping is one-to-many |
| 78 | for some providers (one `polaris` integration backs both `polaris_sast` and `polaris_sca` |
| 79 | scans). Pick the `--tool` value from the scan's true kind, and the `--integration-id` from |
| 80 | whatever integration attributes the upload. |
| 81 | - Prefer the dedicated subcommand over `pixee api /api/v1/integrations` for discovery. The |
| 82 | subcommand pages transparently and surfaces the same fields without the HAL envelope when |
| 83 | text mode is enough. |