> ## Documentation Index
> Fetch the complete documentation index at: https://developer.vanta.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Integrations in Vanta

> What an integration is in Vanta, the difference between public and private integrations, and how they work.

In Vanta, an **integration** is a connection between your Vanta tenant and an external system that pushes data **into** Vanta on a recurring schedule. That data is modeled as [**resources**](/docs/concepts/resources) — user accounts, devices, vulnerabilities, training records, background checks, and custom shapes you define yourself — and Vanta runs automated tests against them to produce compliance evidence.

Vanta supports 400+ prebuilt integrations for common cloud providers, identity providers, MDMs, and SaaS tools. You can also build your own integrations using the [Build Integrations API](/reference/build-integrations/overview) — either as a Vanta partner publishing to the marketplace, or as a Vanta customer connecting a system Vanta doesn't natively support.

<Info>
  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](/reference/manage-vanta/overview) instead.
</Info>

## 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](https://help.vanta.com/hc/en-us/articles/28012720726036-Creating-Custom-Tests) you author for [custom resources](/docs/concepts/resources#custom-resources) — and turns the synced data into pass/fail evidence.

Everything an integration pushes goes through Vanta's [resource model](/docs/concepts/resources): built-in types like `UserAccount`, `Computer`, `Vulnerability`, `BackgroundCheck`, and `TrainingRecord` come with prebuilt tests, and `CustomResource` lets you define your own schema when none of the built-ins fit.

An integration is scoped to the resources it owns. It can push that state in with `PUT /v1/resources/<type>` and read it back with `GET /v1/resources/<type>`, but it can't access other tenant data or change any tenant settings.

## 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](https://app.vanta.com/integrations); 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](/docs/guides/become-partner) and a marketplace review             | Self-serve in the [Developer Console](https://app.vanta.com/settings/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](/docs/quickstart/build-integration)                                      | [Build a Private Integration](/docs/quickstart/build-private-integration)               |

### 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 need to connect the integration to your existing Vanta tenant.
* You want to layer [Custom Tests](https://help.vanta.com/hc/en-us/articles/28012720726036-Creating-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](/docs/concepts/resources). The main differences are authorization (authorization-code vs client-credentials), distribution (marketplace vs single tenant) and support for custom resources and tests.

### 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](/docs/guides/become-partner).

## Integrations only use the Build Integrations API

Every integration — public or private — is built against the [**Build Integrations API**](/reference/build-integrations/overview). That's the only Vanta API that accepts data being pushed in from an external system for automated compliance monitoring.

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

| API                                                              | What it does                                                                            | Who uses it                                   |
| ---------------------------------------------------------------- | --------------------------------------------------------------------------------------- | --------------------------------------------- |
| [**Build Integrations**](/reference/build-integrations/overview) | Push resources and evidence into Vanta tenants.                                         | Partners and customers building integrations. |
| [**Manage Vanta**](/reference/manage-vanta/overview)             | Automate workflows inside your tenant — controls, tests, vendors, personnel, documents. | Vanta customers automating their own tenant.  |
| [**Conduct an Audit**](/reference/audits/overview)               | Run audits, manage auditors, sample evidence.                                           | Auditor firms.                                |

These APIs **do not mix**. An application is created in the [Developer Console](https://app.vanta.com/settings/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.

<Warning>
  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.
</Warning>

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.

Scanners often emit thousands of findings spanning Critical, High, Medium, and Low CVEs alongside Known malware and Protestware / potentially unwanted behavior alerts. Customers overwhelmingly act on Critical and High in Vanta — those are the severities that drive compliance monitoring. If a customer's sync would exceed the [payload limits](/reference/build-integrations/overview#payload-limits), send only Critical and High, or let customers pick which severities to sync at install time.

### HR and security training monitoring

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.

### Evidence file uploads

Upload documents and evidence (`PDF`, screenshots, exports) directly to Vanta. Useful for any workflow that produces a periodic report or evidence collected in a file format.

### Custom data Vanta doesn't natively model

Use a [custom resource](/docs/concepts/resources#custom-resources) to define your own schema — internal servers, on-prem appliances, change-management records, vendor review artifacts — and pair it with a [Custom Test](https://help.vanta.com/hc/en-us/articles/28012720726036-Creating-Custom-Tests) to define what "compliant" means. This is how teams cover environments and data shapes that aren't in the supported resource list.

## Related

<CardGroup cols={2}>
  <Card title="Build a private integration" icon="rocket" href="/docs/quickstart/build-private-integration">
    Connect a homegrown app, on-prem system, or unsupported SaaS tool to your own Vanta tenant.
  </Card>

  <Card title="Build a public integration" icon="share-nodes" href="/docs/quickstart/build-integration">
    Become a Vanta partner and publish to the marketplace.
  </Card>

  <Card title="Resources" icon="cube" href="/docs/concepts/resources">
    The resource model integrations push data into — built-in and custom.
  </Card>

  <Card title="Build Integrations API" icon="plug" href="/reference/build-integrations/overview">
    Endpoint reference for everything an integration can call.
  </Card>
</CardGroup>
