Scope resources in or out

Control which resources synced from a connected integration are tested and used as compliance evidence, using the Manage Vanta API.

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.

1. 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 → Tokens expire after one hour.

   Don't know the integrationId or resourceKind?

   Call GET /v1/integrations to list connected integrations, their connectionIds, and the resourceKinds they expose (e.g. aws, gcp, okta, snowflake).

   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.

2. 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.

   Node.js

   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());
   

   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.