--- title: "Get fix computation" method: GET path: "/orgs/{org_slug}/fixes/computations/{computation_id}" tags: ["fixes"] --- # Get fix computation `GET /orgs/{org_slug}/fixes/computations/{computation_id}` ## Request - Base URL: `https://api.socket.dev/v0` - URL: `https://api.socket.dev/v0/orgs/{org_slug}/fixes/computations/{computation_id}` - Auth: one of: - HTTP bearer - HTTP basic Returns the status of a computation started with [Start fix computation](https://docs.socket.dev/reference/start-fix-computation), and its result once it has succeeded. This endpoint always responds quickly. While `status` is `pending` or `running`, wait a few seconds and poll again. When `status` is `failed`, `failureReason` and `failureDetail` describe the failure. Start a new computation to retry. ## Result Structure When `status` is `succeeded`, `result` contains a `fixDetails` object where each key is a vulnerability ID (GHSA or CVE) and the value is a discriminated union based on the `type` field. ### Common Fields All response variants include: - `type`: Discriminator field (one of: "fixFound", "partialFixFound", "noFixAvailable", "fixNotApplicable", "errorComputingFix") - `value`: Object containing the variant-specific data The `value` object always contains: - `ghsa`: string | null - The GHSA ID - `cve`: string | null - The CVE ID (if available) - `advisoryDetails`: object | null - Advisory details (only if include_details=true) ### Response Variants **fixFound**: A complete fix is available for all vulnerable packages - `value.fixDetails.fixes`: Array of fix objects, each containing: - `purl`: Package URL to upgrade - `fixedVersion`: Version to upgrade to - `manifestFiles`: Array of manifest files containing the package - `updateType`: "patch" | "minor" | "major" | "unknown" - `overrides`: (optional, only with `allow_overrides=true`) Array of `{ parentPurl }`, one per installed parent whose declared range rejects `fixedVersion`. Apply the fix by forcing `fixedVersion` for this package under each parent with a scoped npm override, pnpm override or yarn resolution. Only npm packages get one. - `value.fixDetails.responsibleDirectDependencies`: (optional) Map of direct dependencies responsible for the vulnerability **partialFixFound**: Fixes available for some but not all vulnerable packages - Same as fixFound, plus: - `value.fixDetails.unfixablePurls`: Array of packages that cannot be fixed, each containing: - `purl`: Package URL - `manifestFiles`: Array of manifest files - `reasons`: Human-readable explanations of why the package cannot be upgraded. May contain multiple distinct entries when different dependency chains are blocked for different causes (e.g. one chain has no compatible upstream version; another would require a major version bump skipped by `--no-major-updates`). - `dependencyChain`: (optional) Installed PURLs along the dependency chain where the fix search was blocked, from the blocking package down to this package. Present only when a chain was recorded; the first `reasons` entry describes this chain. - `dependencyChainPicks`: (optional) Version the fix search had tried for a `dependencyChain` package before the path dead-ended, keyed by that package's installed PURL. These picks were rolled back with the failure, so they are not applied; packages the search never moved are absent. - `withheldFix`: (optional) Present when a fix exists but this request's policy withheld it: `{ purl, version, reason }` where `purl` is the package (without version), `version` the lowest safe version the policy removed from the fix search, and `reason` one of `majorUpdate` (a major update while `allow_major_updates=false`), `releaseAge` (younger than `minimum_release_age`) or `publishDateUnknown` (publish date unavailable, so `minimum_release_age` cannot be verified). The two release age reasons only occur for ecosystems `minimum_release_age` applies to, which `minimum_release_age_ecosystems` can narrow, and never for versions `minimum_release_age_exclude` exempts. Lifting the policy is not guaranteed to make the fix applicable — other version constraints in the dependency tree may still block this version. **noFixAvailable**: No fix exists for this vulnerability (no patched version published) - `value.vulnerableArtifacts`: Array of vulnerable packages with their manifest files; each carries a static `reasons` entry stating that no patched version has been published **fixNotApplicable**: A patched version of the vulnerable package exists but cannot be applied. The most common cause is that there is no upgrade path through the dependency tree — for example, given a chain `App → A@1.0.0 → B@1.0.0` where `B < 2.0.0` is vulnerable, if no version of `A` accepts `B@2.0.0` the fix cannot be applied without a manual override (e.g. `pnpm overrides`). For npm packages, `allow_overrides=true` returns such a fix with `overrides` instead. Other causes include callers passing `--no-major-updates` when the only patched version is a major bump. - `value.vulnerableArtifacts`: Array of vulnerable packages with their manifest files, each with per-artifact `reasons` explaining why the fix could not be applied (always at least one entry; a static fallback when the fix search reported no per-package cause) and an optional `dependencyChain` — installed PURLs from the package that blocked the upgrade down to the vulnerable package, present when a chain was recorded (the first `reasons` entry describes it), an optional `dependencyChainPicks` — the version the fix search had tried for a chain package before the path dead-ended (rolled back with the failure), keyed by installed PURL — and an optional `withheldFix` — present when a fix exists but this request's policy withheld it (see the partialFixFound field list) **errorComputingFix**: An error occurred while computing fixes - `value.message`: Error description ### Fix version alignment When several requested vulnerabilities are fixed by upgrading the same package, their fix entries carry the SAME `fixedVersion` — the server computes a version that clears all of them together and verifies it against each advisory's affected ranges. Clients can apply the fixes per package without reconciling versions. Only when no single in-policy version fixes all advisories on a package (non-monotonic affected ranges) can entries differ; each is then the minimal upgrade for its own advisory. ### Advisory Details (when include_details=true) - `title`: string | null - `description`: string | null - `cwes`: string[] - CWE identifiers - `severity`: "LOW" | "MODERATE" | "HIGH" | "CRITICAL" - `cvssVector`: string | null - `publishedAt`: string (ISO date) - `kev`: boolean - Whether it's a Known Exploited Vulnerability - `epss`: number | null - Exploit Prediction Scoring System score - `affectedPurls`: Array of affected packages with version ranges ### Stateful Alert IDs (when include_stateful_alert_ids=true) The `statefulAlertIds` field, next to `fixDetails`, maps each GHSA ID to an array of open stateful alert IDs (the human-readable `SOCKET-XXX-N` identifiers also returned by `/v0/orgs/{org_slug}/alerts`). The lookup is org-scoped, so the same GHSA may map to multiple alert IDs when it appears in alerts across different repos or branches. Callers that need a repo/branch filter should intersect this map with results from the alerts API. Because the lookup spans every repository in the organization, callers limited to some of its repositories get a 403 when they set this flag. The lookup honors the same scan-type visibility as `/v0/orgs/{org_slug}/alerts` — when the `enableTier1OrgAlertApiRead` feature flag is off for the org, only `socket` scans are visible (no `socket_tier1`). Note on scopes: this field surfaces identifiers that are otherwise reachable via `/v0/orgs/{org_slug}/alerts` (which requires `alerts:list`). The fixes route is gated on `fixes:list` alone; the GHSAs the alert IDs are keyed to are already part of every `/fixes` response, and exposing the matching alert IDs through this opt-in flag is intentional — it lets a caller with only `fixes:list` complete the correlation back to /alerts on a token that already has that scope. If you require strict scope separation, do not enable this flag. This endpoint consumes 0 units of your quota. This endpoint requires the following org token scopes: - fixes:list ## Path parameters - `org_slug` string, required - `computation_id` string, required ## Response `200` The computation status, including the fixes payload once succeeded - object - `id` string, required - `status` 'pending' | 'running' | 'succeeded' | 'failed', required: Lifecycle state of the fix computation - `createdAt` string, required - `startedAt` string - `finishedAt` string - `failureReason` string - `failureDetail` string - `result` object - `fixDetails` object, required - `allDetectedGhsas` string[]: All vulnerability GHSA IDs detected in the project, regardless of the vulnerability_ids filter. Only present when include_all_detected_ghsas=true is set. - `statefulAlertIds` object: Map of GHSA ID → open stateful alert IDs detected in this organization. Lets callers correlate /fixes results back to the alert IDs they see in /v0/orgs/{org_slug}/alerts. Org-scoped, not repo/branch-scoped — the same GHSA may surface in multiple alerts across repos. Only present when include_stateful_alert_ids=true is set. ## Other responses - `400`: Bad request - `401`: Unauthorized - `403`: Insufficient max_quota for API method - `404`: Resource not found - `429`: Insufficient quota for API route ## Changes - **2026-11-03** `5ad8bf36b1e7`: 1 info - endpoint added [Operation history](https://skmtc.dev/socket-dev/apis/socket/changes/orgs/:org_slug/fixes/computations/:computation_id/get.md) --- [API](https://skmtc.dev/socket-dev/apis/socket.md) - [All operations](https://skmtc.dev/socket-dev/apis/socket/llms.txt) - [OpenAPI document](https://skmtc.dev/socket-dev/apis/socket/revisions/5ad8bf36b1e7?raw)