Resources

What a resource is in Vanta, how to create one, and when to use a custom resource.

In Vanta, a resource is any entity you push into Vanta from an external system — user accounts, devices, vulnerabilities, code repositories, or anything you model with a custom schema. Once a resource type is defined, you can sync data to it through the API and Vanta will run automated tests against it for evidence collection.

Use this page when you’re building an integration that sends data into Vanta. To manage data that Vanta-built integrations already pull in, see the Manage resources guides instead.

Resource types

Every resource is created from a base resource type that defines its schema:

• Built-in base types — Vanta ships predefined schemas for common entities like user accounts, devices, vulnerabilities, and code repositories. These come with prebuilt tests, reports, and product surfaces out of the box.
• CustomResource — a generic base type that lets you define the entire schema yourself. Use this when none of the built-in types fit the data you need to sync.

Always prefer an existing base resource type when one fits your use case. Custom resources are a flexible escape hatch, not the default — picking a built-in type gives you Vanta’s prebuilt tests, reports, and product surfaces for free.

User account resources

Sync user accounts from your custom system so Vanta can run access and offboarding tests against them.

Supported resource types

Full reference of every resource type Vanta accepts.

Create a resource

In the Resources tab, locate and select the + Create Resource button.

The Create a Resource form will open. Complete the required fields and click create.

• Resource Type is the name used to identify the resource being sent.

• Base Resource Type defines the structure and schema of the resource. All schemas follow the JSON type definition model.

  • Vanta provides several base types with predefined schemas (covered in the linked guides above).
    • These predefined properties — and any custom properties you add — can be referenced in custom tests.
  • Vanta also provides a generic CustomResource type that lets you define the entire schema yourself via the Custom Properties section.

• Custom Properties extend the base resource type with additional fields. Currently supported types: boolean, int32, string, timestamp.

• Generated schema shows the complete structure of the resource based on the base type and custom properties. It’s not editable directly, but the body of every API sync request must align with it. The schema remains accessible after creation.

Created resources appear under the Resources tab with their corresponding resource ID and schema.

The Resource ID is the key value you’ll use when making sync requests to the Vanta API.

Custom resources

A custom resource is a resource created from the CustomResource base type. Use it when none of Vanta’s built-in base types (user accounts, devices, vulnerabilities, code repositories, and so on) fit the data you need to sync.

Custom resources behave like any other resource once created: you sync them through the Vanta API, and Vanta runs automated tests against them for evidence collection.

When to use a custom resource

Reach for a custom resource when:

• The entity you’re syncing isn’t represented by an existing base resource type.
• You need to track data that doesn’t map cleanly onto user accounts, devices, vulnerabilities, or repositories.
• You’re modeling something unique to your environment — for example, a fleet of internal-only servers, a custom inventory record, or a domain-specific compliance artifact.

If your data fits a built-in base type, use that type instead. You can still extend built-in types with custom properties without switching to a custom resource.

Pair custom resources with custom tests

Vanta only runs tests against resources it knows how to evaluate. Built-in base types ship with prebuilt tests, but a custom resource has no tests until you create them.

To get value out of a custom resource, you need to build a Custom Test that evaluates its data and reports pass/fail per resource.

Without a custom test, a custom resource is just a passive data record — it won’t contribute evidence to controls.

Schema model

A custom resource’s schema has two parts:

1. Default properties — every custom resource includes:
   • displayName — human-readable name shown in Vanta
   • uniqueId — stable identifier for the resource in your system
   • externalUrl — link back to the resource in its source system
2. Custom properties — fields you define using JSON Type Definition (JTD) format.

Always add custom properties when creating a custom resource. A custom resource without custom properties only has the three default fields and provides no useful surface to test against — if that’s all you need, a different base resource type is almost certainly a better fit.

Supported property types

Custom properties must be one of:

Type	Description
boolean	true or false
int32	Numeric integer values
string	Text
timestamp	ISO 8601 date-time values (for example, 2024-01-15T10:30:00Z)

Example schema

A minimal Server resource defined as a custom resource might use this JTD:

{
  "properties": {
    "name": { "type": "string" },
    "active": { "type": "boolean" },
    "memory": { "type": "int32" },
    "lastUpdated": { "type": "timestamp" }
  }
}

This produces a resource with name, active, memory, and lastUpdated on top of the default displayName, uniqueId, and externalUrl fields. Each property is then available to reference in custom tests.

Sync model

Custom resources are synced through a single endpoint:

/v1/resources/custom_resource

There are two operations:

• List (GET) — returns every resource currently stored under a given resourceId.
• Sync (PUT) — replaces the full set of resources for a given resourceId with the payload you send.

Sync is full-state, not incremental. Every PUT must contain the complete set of resources you want Vanta to monitor. Any resource omitted from a sync is treated as no longer existing and will be marked as deleted.

In practice, this means your integration should compute the full current state of resources on every run and send all of them in a single PUT, rather than sending diffs.

For request and response details — URLs, headers, parameters, and example payloads — see the Build Integrations API reference.

Lifecycle

A typical custom resource lifecycle looks like this:

1. Create the resource type in the Vanta UI under Resources → + Create Resource, choosing CustomResource as the base type and defining your custom properties.
2. Capture the Resource ID generated after creation. You’ll pass it on every API call.
3. Sync data by PUTing the full set of resources to /v1/resources/custom_resource on whatever cadence makes sense for your data (typically on a recurring schedule).
4. Build custom tests that evaluate the synced data and produce evidence against your controls.
5. Iterate on the schema as your needs change — adding custom properties is supported, but expect to update both your sync payloads and any tests that reference them.

Related

User account resources

Use the built-in UserAccount base type for user data.

Build integrations API

Reference for the resource sync and list endpoints.

Custom tests

Build the tests that evaluate your custom resource data.

Supported resource types

Full reference of every resource type Vanta accepts.