Scope resources in or out

This guide flips resources synced from a connected integration in or out of scope using PATCH /v1/integrations/{integrationId}/resource-kinds/{resourceKind}/resources on the Manage Vanta API. Out-of-scope resources stay visible in the inventory but stop counting as compliance evidence and stop running through tests. The build prompt below generates a scheduled job that applies regex-based scoping rules — like “exclude every dev-* GCP project” — in batches of 50.

Before you begin

This guide is for Vanta admins managing data inside their own Vanta account. You’ll need:

A Manage Vanta API token.
The token must have scopes vanta-api.all:read and vanta-api.all:write.
At least one connected integration whose resources you want to scope.

Vanta-built integrations pull in resources — user accounts, cloud instances, code repositories, and more — that get tested for compliance. Marking a resource inScope: false excludes it from those tests entirely. Use it for sandbox accounts, test instances, or systems explicitly outside your audit boundary.

Want to know which resources are scopable before you write code? GET /v1/integrations/{integrationId}/resource-kinds/{resourceKind} returns isScopable: true|false along with numResources / numInScope counters.

Find the resources you want to scope

Your terminal — pick the integrationId and resourceKind you’re targeting, then list resources with the filters you care about. Common choices: isInScope=true to find things to scope out, or isInScope=false to bring something back in.

Terminal

curl 'https://api.vanta.com/v1/integrations/gcp/resource-kinds/GCPComputeInstance/resources?connectionId=663e78b85360cc947add64bd&isInScope=true&pageSize=50' \
  -H 'Accept: application/json' \
  -H 'Authorization: Bearer YOUR_TOKEN'

Response (truncated)

{
  "results": {
    "data": [
      {
        "responseType": "ComputeInstance",
        "resourceKind": "GCPComputeInstance",
        "resourceId": "663e78bb5360cc947addd5f3",
        "connectionId": "663e78b85360cc947add64bd",
        "displayName": "vm-backend-service-2",
        "owner": "61a66a98538a952a6533f540",
        "inScope": true,
        "description": "GCP Compute Instance",
        "account": "amalgamated-widgets-demo",
        "region": "us-central1-a"
      }
    ],
    "pageInfo": { "hasNextPage": false, "endCursor": "..." }
  }
}

Copy each resourceId you want to update — you’ll send them in Step 2.

Got a 401?

Token is expired (one-hour lifetime), missing, or lacks vanta-api.all:read. Mint a fresh one — see Authentication → Token expiration.

Don't know the integrationId or resourceKind?

Neither value is fixed across accounts. Discover both from your own tenant:

Call GET /v1/integrations to list your connected integrations. The integrationId is a lowercase slug like aws, gcp, okta, or snowflake.
Call GET /v1/integrations/{integrationId}/resource-kinds to list the resource kinds that integration exposes (e.g. GCPComputeInstance). Both values are case-sensitive in the resource paths.

Multiple connections for the same integration?

Pass connectionId=<id> to filter to a single connection (e.g. one of two GCP projects). Without it, the response covers every connection for that integration.

Resource kind isn't scopable?

Some resource kinds (e.g. policy compliance results) can’t be scoped out — isScopable will be false on the resource-kind details. Trying to update those will return an error.

Update scope in bulk

Your terminal — PATCH /v1/integrations/{integrationId}/resource-kinds/{resourceKind}/resources with an updates array. Each entry is keyed by id (the resourceId) and may set inScope, ownerId, and/or description.

const INTEGRATION_ID = "gcp";
const RESOURCE_KIND = "GCPComputeInstance";

const res = await fetch(
  `https://api.vanta.com/v1/integrations/${INTEGRATION_ID}/resource-kinds/${RESOURCE_KIND}/resources`,
  {
    method: "PATCH",
    headers: {
      "Content-Type": "application/json",
      Authorization: "Bearer YOUR_TOKEN",
    },
    body: JSON.stringify({
      updates: [
        { id: "663e78bb5360cc947addd5f3", inScope: false },
        { id: "663e78bb5360cc947addd611", inScope: false },
      ],
    }),
  },
);
console.log(await res.json());

import requests

INTEGRATION_ID = "gcp"
RESOURCE_KIND = "GCPComputeInstance"

r = requests.patch(
    f"https://api.vanta.com/v1/integrations/{INTEGRATION_ID}/resource-kinds/{RESOURCE_KIND}/resources",
    headers={"Authorization": "Bearer YOUR_TOKEN"},
    json={
        "updates": [
            {"id": "663e78bb5360cc947addd5f3", "inScope": False},
            {"id": "663e78bb5360cc947addd611", "inScope": False},
        ]
    },
)
r.raise_for_status()
print(r.json())

curl -X PATCH 'https://api.vanta.com/v1/integrations/gcp/resource-kinds/GCPComputeInstance/resources' \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json' \
  -H 'Authorization: Bearer YOUR_TOKEN' \
  -d '{
    "updates": [
      { "id": "663e78bb5360cc947addd5f3", "inScope": false },
      { "id": "663e78bb5360cc947addd611", "inScope": false }
    ]
  }'

Expected response (200) — a per-resource result so you can tell which entries failed:

{
  "results": [
    { "id": "663e78bb5360cc947addd5f3", "status": "SUCCESS" },
    { "id": "663e78bb5360cc947addd611", "status": "SUCCESS" }
  ]
}

The bulk endpoint accepts up to 50 resources per call. Page through Step 1 and call this endpoint in batches if you have more.

Got an ERROR in results?

The message field tells you which entry failed and why — typically because the id doesn’t belong to that (integrationId, resourceKind) or the resource kind isn’t scopable. Successful entries are still applied; only fix and retry the failures.

Got a 404 on the path?

The integrationId or resourceKind is wrong. They’re case-sensitive — gcp and GCPComputeInstance are different fields. Re-run Step 1 to confirm the exact spellings.

Got a 403?

Your token has vanta-api.all:read but not vanta-api.all:write. Mint a token with both scopes.

Updating one resource at a time? Use PATCH /v1/integrations/{integrationId}/resource-kinds/{resourceKind}/resources/{resourceId} with { "inScope": false }. It returns 204 No Content on success and is the right call when you’re reacting to a single event (e.g. a webhook from your tagging system).

Congratulations

You’ve taken control of which resources Vanta tests against. Out-of-scope resources are skipped by automated tests and won’t show up as failing entities, while staying visible in your inventory for traceability. The change is captured in your audit log.

Next steps

Add owners and descriptions

For everything that stays in scope, ensure each resource has an active owner and description.

Query failing tests

Confirm a previously-failing test no longer flags the resource you scoped out.

Try it in Postman

Import the collection and run the bulk PATCH against a sandbox in seconds.

Manage Vanta API reference

Browse every Manage Vanta endpoint — integrations, resources, controls, tests, documents.

Get Started

Guides

Concepts

Build for Vanta customers

Tools and Platform

Before you begin

Congratulations

Next steps

Add owners and descriptions

Query failing tests

Try it in Postman

Manage Vanta API reference

​Before you begin

​Congratulations

​Next steps

Add owners and descriptions

Query failing tests

Try it in Postman

Manage Vanta API reference

Before you begin

Congratulations

Next steps