Who is this API for?
This API is the only Vanta API available to partners and is the right choice for any app that ships data into Vanta.Automating workflows inside your own Vanta tenant — assigning control owners, querying tests, managing vendors and personnel? Use the Manage Vanta API instead. (Note: the Manage Vanta API is not available to partners.)
When to use this API
Reach for Build Integrations endpoints when you want to:- Publish a public integration to the Vanta marketplace so any Vanta customer can connect your tool.
- Build a private integration for a homegrown app, on-prem system, or unsupported SaaS tool inside your own tenant.
- Sync resources Vanta doesn’t natively support via custom resources, then layer Custom Tests on top. Custom resources and Custom Tests are a private-integration feature, available to direct Vanta customers building against their own tenant, not to public marketplace integrations.
- Upload file-based evidence on a customer’s behalf to satisfy evidence requests.
Authentication
All Build Integrations apps authenticate with OAuth 2.0 at the same token endpoint. The grant type depends on how your app is distributed:- Private integration — single-tenant, used only inside your own Vanta account. Uses
client_credentials. Start here if you’re building for your own tenant. - Public integration — listed in the Vanta marketplace, installable by any customer. Uses
authorization_codewith refresh tokens, one set per customer authorization.
Private integrations
Grant Type:client_credentials
Your server holds the client_id / client_secret and exchanges them directly for an access_token scoped to your own Vanta tenant.
Request body
refresh_token is issued. Requesting a new token with the same client_id / client_secret immediately revokes the previous one — re-mint just before each sync run.
To revoke access, rotate the client_secret in the Developer Console (this invalidates active tokens immediately) or delete the application. For the full step-by-step setup, see the Build a Private Integration quickstart.
Public integrations
Grant Type:authorization_code
A customer authorizes your app in the browser at /oauth/authorize on their region’s app host (app.vanta.com, app.eu.vanta.com, or app.aus.vanta.com), and Vanta redirects back to your redirect_uri with a short-lived code (valid for 30 seconds). Your server then exchanges the code for a per-customer access_token + refresh_token pair.
The authorize redirect is the only flow that touches the browser-facing app host — and unlike
api.vanta.com, that host is regional: sending an EU or AU customer to app.vanta.com instead of their own region’s host can fail. All token exchanges and API calls still go to api.vanta.com regardless of the customer’s region. For Vanta Gov, use app.vanta-gov.com and api.vanta-gov.com. See Base URLs and regions for the full picture, and the Build a Public Integration quickstart for the full authorize-redirect flow (including state validation and source_id semantics).source_id). Each customer authorization is independent — re-running the flow for the same source_id revokes that customer’s previous tokens, but different customers get separate, isolated token pairs.
Refreshing the token
When the access token expires (1 hour), exchange therefresh_token for a new pair. Every refresh rotates the refresh_token; the previous one stays valid for 3 hours to tolerate transient failures — persist the new one immediately.
cURL
200 OK response shape as the initial exchange (new access_token + new refresh_token).
Revoking access
When a customer disconnects your integration on your side, call the Suspend API so Vanta cleans up its side and revokes the tokens.cURL
200 OK with an empty body {}. Idempotent — calling it on an already-revoked token still returns 200. Returns 401 if the token doesn’t belong to this client_id.
For grant-type tradeoffs, credential hygiene, and other common pitfalls, see Authentication concepts.
Scopes
Most integrations request the first two. Add the document scopes only if your integration uploads evidence files.
Base URL
Usehttps://api.vanta.com, or https://api.vanta-gov.com if you’re on Vanta Gov. See Base URLs for details.
Resource model
Build Integrations endpoints follow aresource_type pattern:
PUT is a “state of the world” sync — any resource you previously pushed but omit from a later PUT is treated as deleted. There is no separate DELETE endpoint. PUT is safe to retry on network errors. Each PUT must carry the full set of resources for its type in a single request; a follow-up PUT replaces the previous payload rather than appending to it. See Payload limits for the per-request caps and how to scope large datasets to stay under them.
Supported resource types
Each resource type below supports bothPUT and GET at /v1/resources/<type>. Open the matching endpoint in the sidebar for its full schema.
For anything not natively supported, private integrations can use the custom resource type. Public marketplace integrations are restricted to the built-in resource types in this table, excluding
custom_resource.
Pagination
Build IntegrationsGET /v1/resources/<type> endpoints are not paginated. Each request returns the full list of resources for the given type in a single resources array:
pageSize, pageCursor, or pageInfo fields. The corresponding PUT /v1/resources/<type> endpoint is a full-state sync and cannot be split across multiple requests for the same type — see Payload limits for how to keep large datasets within the per-request caps.
Payload limits
EachPUT /v1/resources/<type> request is capped at:
Because
PUT is a “state of the world” sync, every resource you want Vanta to retain for a given resource_type must arrive in a single request — a follow-up PUT to the same type replaces the previous payload rather than appending to it. You can split work across resource types (a separate PUT per type), but not within one.
If a payload approaches either cap, scope the sync down to fewer resources to avoid the payload limit.
- Sync only the records you need to act on. This is most relevant for vulnerability resource types (
PackageVulnerabilityConnectors,ApiEndpointVulnerabilityConnectors,StaticAnalysisCodeVulnerabilityConnectors), where scanners often emit thousands of findings spanning Critical, High, Medium, and Low CVEs alongside Known malware and Protestware / potentially unwanted behavior alerts. Customers overwhelmingly take action on Critical and High in Vanta, and those are the severities that drive compliance monitoring. Sending only Critical and High keeps payloads well under the limit and matches what Vanta’s own native scanner integrations do. - Let customers pick severities at install time. For public integrations, expose a severity selector in your install or settings UI so customers opt into what they want synced. Defaulting to Critical and High covers the common case; customers with specific framework requirements can broaden the set themselves.
Computer resources when devices carry large installed-application inventories — sync only the security-relevant applications (password managers, antivirus, etc.) rather than the full list.
Rate limits
Exceeding a limit returns
429 Too Many Requests.
How to retry:
- Vanta doesn’t send a
Retry-Afterheader on429, so pace your own retries rather than waiting for the response to tell you when. - As an example you can sleep 5 seconds on the first
429, then double the delay on each subsequent one (exponential backoff) up to 3 attempts. - The 10/minute limit is per access token — if you operate across many customers, each customer’s token gets its own limits.
- Use one access token per customer for the hour it’s valid; mint and refresh on schedule rather than per request to avoid the
/oauth/tokencap of 25/minute.