Skip to main content

​
About Vanta

Vanta is a security and compliance automation platform covering SOC 2, ISO 27001, HIPAA, vendor risk management, and trust centers. Connecting Vanta to Serval lets workflows read your organizational data - people, vendors, vulnerabilities, frameworks, controls, documents, and trust centers - and upload documents to vendors, security reviews, and existing Vanta documents. Serval only ever sends your credentials to Vanta’s own API. Authentication: OAuth 2.0 client credentials from a Vanta developer application. You supply a Client ID and Client Secret, and Serval exchanges them for an access token automatically on each request - you never handle tokens yourself. Data sync: On demand. Workflows call the Vanta API at the moment they run; there is no background sync or polling. Right after you connect, Serval runs the integration’s health checks once automatically. The optional “Vanta Security Training Compliance Check” workflow runs on a daily schedule once installed, but that is a workflow you choose to enable, not a data sync.

​
What the Vanta integration enables

Anything defined in the Vanta API can be accessed through Serval.

​
Get your credentials

Serval connects with the Client ID and Client Secret of an OAuth application you create in Vanta’s Developer Console. Vanta documents the full process in its API access setup guide.
1

Log in to Vanta as an admin

You need admin access to your Vanta account to create developer applications.
2

Open the Developer Console

Navigate to Settings, then Developer Console.
3

Create the application

Click Create, then configure it: give it a Name (for example, “Serval Integration”), a Description, and set the App Type to Manage Vanta.
4

Copy the credentials

After the app is created, copy the Client ID and Client Secret. You’ll paste both into Serval.
The App Type must be Manage Vanta. Serval requests Vanta’s full read and write scopes (vanta-api.all:read and vanta-api.all:write), which correspond to that app type - see Vanta’s permission scopes documentation. An app created with a more restrictive type does not grant these scopes, and the connection’s health checks will fail.

​
Connect in Serval

1

Instance Name (required)

“A friendly name for this Vanta integration instance (e.g., “Production Vanta”)”. This is purely a label - Vanta has no per-account instance ID, so pick whatever helps you tell connections apart. Leaving it blank shows “This field is required”.
2

Client ID (required)

“The Client ID from your Vanta OAuth application”. Paste the Client ID you copied from the Developer Console. Leaving it blank shows “This field is required”.
3

Client Secret (required)

“The Client Secret from your Vanta OAuth application”. Paste the Client Secret. After saving, it is stored encrypted and displays masked (bullet characters plus the last 4 characters).
4

Save and verify

Save the connection. Serval automatically runs the integration’s health checks once so you can confirm everything works right away.
Editing the connection later: the saved Client Secret displays masked, with a control to replace it. Leave it untouched - or blank after choosing to replace it - to keep your stored secret; it only changes when you enter a new value. Client ID and Instance Name come back pre-filled with their saved values and must stay filled in when saving an update, even if you’re only rotating the secret.

​
Verifying the connection

The Vanta integration ships three health checks. They run automatically right after you connect (and again when you save changes to the connection), and can be re-run any time: Test Vanta Connection - verifies Serval can reach Vanta and list the people in your organization.
  • Success: “Successfully connected to Vanta. Found people in the organization.”
  • Failure: “Unable to connect to Vanta. Please verify your API token is valid.”
List Vanta Vendors - confirms the connection can list your vendors, and returns a few sample vendors (name, status, inherent risk level) in the result.
  • Success: “Successfully listed vendors from Vanta (sample size: [number])”
  • Failure: “Unable to list vendors from Vanta. Please verify your API token has the required permissions.”
List Vanta Vulnerabilities - confirms the connection can list vulnerabilities, and returns a few samples (severity, status, CVE ID) in the result.
  • Success: “Successfully listed vulnerabilities from Vanta (sample size: [number])”
  • Failure: “Unable to list vulnerabilities from Vanta. Please verify your API token has the required permissions.”
A failure message mentioning permissions (“Please verify your API token has the required permissions”) usually means your Vanta OAuth app was created with a more restrictive App Type than Manage Vanta. Recreate the app with the Manage Vanta type and update the connection with the new Client ID and Client Secret.

​
Gotchas and troubleshooting

Serval requests Vanta’s full read and write scopes, which correspond to the Manage Vanta app type. If your OAuth app was created with a more restrictive type, those scopes are not granted and the health checks fail. Recreate the app with the Manage Vanta type per Vanta’s permission scopes documentation, then update the connection with the new Client ID and Client Secret.
All three health-check failure messages reference “your API token”, but this integration authenticates with OAuth client credentials. When a check fails, verify the Client ID and Client Secret from your Vanta OAuth application (and that its App Type is Manage Vanta) - there is no token to check.
When editing a saved connection, Serval rejects the update if Client ID or Instance Name is empty - even if you only want to rotate the secret. Both come pre-filled with their saved values, so just don’t clear them. The Client Secret is the only field you can leave unchanged: leaving it untouched or blank keeps the stored secret intact.
The vendor lookup (used by the “Get Vanta Vendor ID by Name” workflow) tries a case-insensitive exact name match first, then falls back to partial matching. It fails when no vendor matches, and also when more than one vendor partially matches. Use a more specific name, or list all vendors and pick the exact vendor from the results.
Uploads to a vendor or a vendor security review validate the document type first. Only 16 types are accepted - values such as CONTRACT, SOC2_REPORT, PENETRATION_TEST_REPORT, ANSWERED_QUESTIONNAIRE, BAA_FILE, DPA_FILE, ISO_27001_REPORT, and OTHER. An invalid type fails immediately with a message listing the valid types (“Valid types are: …”), and no upload happens. Uploads to an existing Vanta document don’t take a document type, so this check doesn’t apply there.
Serval automatically adds Vanta’s “v1” version prefix to API request paths when it’s missing, so workflow builders should write paths without it. If a request returns an unexpected “not found” error, check the resource path itself - a missing version prefix is not the cause, since Serval adds it for you.
Vanta has no per-account or per-instance identifier, so Serval generates its own internal ID for the connection and uses the Instance Name purely as a display label. Renaming it later is safe and changes nothing about the connection.
The upload steps that take a Serval attachment (upload to a vendor, to a security review, or to an existing document) first resolve the attachment within your Serval team before uploading it to Vanta. They need the workflow’s Current Team context in addition to the Vanta connection - if a document upload fails before reaching Vanta, check that the workflow has team context available.
Need help? Contact support@serval.com for assistance with your Vanta integration.