Integrations

What an integration is in Vanta, the difference between public and private integrations, and why they only use the Build Integrations API.

In Vanta, an integration is a connection between your Vanta tenant and an external system that pushes data into Vanta on a recurring schedule. Integrations are how user accounts, devices, vulnerabilities, training records, background checks, and custom resources get into Vanta so it can run automated tests against them and produce compliance evidence.

Vanta ships 300+ prebuilt integrations for common cloud providers, identity providers, MDMs, and SaaS tools. This page is about the integrations you build on top of the Build Integrations API — either as a Vanta partner publishing to the marketplace, or as a Vanta customer connecting a system Vanta doesn’t natively support.

Automating workflows inside your own tenant — assigning control owners, querying tests, managing vendors and personnel? That’s not an integration. Use the Manage Vanta API instead.

What an integration does

Every integration follows the same shape:

1. Authenticate with Vanta over OAuth 2.0 to get an access_token.
2. Compute the full current state of the resources it owns from the source system.
3. Push that state to Vanta with PUT /v1/resources/<type> on a recurring cadence (typically hourly).
4. Vanta runs automated tests — built-in for supported resource types, or Custom Tests you author for custom resources — and turns the synced data into pass/fail evidence.

The data flow is one-directional: integrations are about getting data into Vanta. They don’t read or modify anything else in the tenant.

Public vs private integrations

There are two kinds of integrations, and choosing between them is the first decision you make.

	Public integration	Private integration
Audience	Vanta partners / ISVs	Vanta customers
Distribution	Listed in the Vanta marketplace; any Vanta customer can install	Single-tenant; only used inside your own Vanta account
OAuth flow	Authorization code with per-customer access_token and refresh_token	Client credentials with a single access_token
Setup	Requires becoming a Vanta partner and a marketplace review	Self-serve in the Developer Console
Data scope	Pushes data into each customer’s tenant on their behalf	Pushes data into your own tenant only
Quickstart	Build a Public Integration	Build a Private Integration

Public integrations

Public integrations are the path for software companies that want their product to be installable by any Vanta customer. You build it once, list it in the Vanta marketplace, and customers self-install it through OAuth — your server then pushes their data into their tenant on a schedule.

Pick a public integration when:

• You sell a SaaS product whose data Vanta customers want to use as evidence (identity, devices, vulnerabilities, HR, ticketing, training, vendor management, etc.).
• You’re willing to host a server-side OAuth client and a per-customer sync job.
• You want a marketplace listing and co-marketing as part of the Vanta Integration Partner Program.

Private integrations

Private integrations are how a Vanta customer connects something that isn’t already in the marketplace — a homegrown app, an on-prem system, or a SaaS tool Vanta doesn’t natively support. They never get published; the integration only exists inside your tenant.

Pick a private integration when:

• You need to feed data from an internal or unsupported system into your own Vanta account.
• You don’t need per-customer authorization — you control both ends.
• You want to layer Custom Tests on top of data Vanta wouldn’t otherwise see.

Both kinds of integration use the same set of endpoints under /v1/resources/<type> and the same resource model. The only differences are authorization (authorization-code vs client-credentials) and distribution (marketplace vs single tenant).

Integrations only use the Build Integrations API

Every integration — public or private — is built against the Build Integrations API. That’s the only Vanta API that accepts data being pushed in from an external system, and it’s the only API a partner can use at all.

Vanta exposes three APIs, each with its own application type, scopes, and surface:

API	What it does	Who uses it
Build Integrations	Push resources and evidence into Vanta tenants.	Partners and customers building integrations.
Manage Vanta	Automate workflows inside your tenant — controls, tests, vendors, personnel, documents.	Vanta customers automating their own tenant.
Conduct an Audit	Run audits, manage auditors, sample evidence.	Auditor firms.

These APIs do not mix. An application is created in the Developer Console under exactly one type — Build Integrations, Manage Vanta, or Conduct an Audit — and that choice determines which scopes it can request and which endpoints its tokens can hit.

A Build Integrations access_token cannot call Manage Vanta or Auditor endpoints, and vice versa. Requesting a scope from a different app type returns invalid_scope; calling an endpoint outside your app’s surface returns 403. There is no shared credential, no token swap, and no way to “promote” one app type into another.

In practice this means:

• An integration that pushes user accounts cannot also assign control owners, query test results, or manage vendors. Those live in the Manage Vanta API.
• A Manage Vanta automation script cannot push resources or upload evidence on a customer’s behalf. That lives in the Build Integrations API.
• Partners cannot use the Manage Vanta or Auditor APIs at all. The Build Integrations API is the entire surface available to a partner.
• If a single workflow needs both — for example, a customer wants to push custom resources and auto-assign owners to the controls those resources feed — they need two separate applications, each with its own credentials, running side by side.

This separation is intentional. It keeps partner integrations scoped to data they’re allowed to push, and it prevents an integration token leak from also exposing tenant-wide configuration.

Use cases

The integrations Vanta customers and partners build cluster around a handful of patterns.

Identity and access reviews

Push UserAccount records from an identity source — your homegrown app’s user table, a niche IdP, or an HR system — so Vanta can run access reviews against the same people that auditors will ask about. This is the most common starting point for both public and private integrations.

Device compliance

Sync Computer records (Windows, macOS, Linux) from an MDM, agent, or asset inventory so Vanta’s device-posture tests can verify disk encryption, screen lock, OS version, and antivirus status across every employee laptop.

Vulnerability monitoring

Push Vulnerability records from a scanner, dependency tool, or code-repo finding source. Vanta tracks SLAs, surfaces overdue vulnerabilities, and reports remediation evidence to auditors automatically.

HR and training evidence

Sync BackgroundCheck and TrainingRecord resources from the HRIS, background-check vendor, or LMS that owns them. Vanta links each record to the right person and produces the per-employee evidence auditors expect.

Custom data Vanta doesn’t natively model

Use a custom resource to define your own schema — internal servers, on-prem appliances, change-management records, vendor review artifacts — and pair it with a Custom Test to define what “compliant” means. This is how teams cover environments and data shapes that aren’t in the supported resource list.

Evidence file uploads

Integrations granted the document scopes can also upload file-based evidence (PDF, screenshots, exports) directly to a customer’s evidence requests with self:write-document. Useful for any workflow that produces a periodic report.

Related

Build a private integration

Connect a homegrown app, on-prem system, or unsupported SaaS tool to your own Vanta tenant.

Build a public integration

Become a Vanta partner and publish to the marketplace.

Resources

The resource model integrations push data into — built-in and custom.

Build Integrations API

Endpoint reference for everything an integration can call.