Sign in

v1

latestOpenAPI 3.0.1Vanta Terms of Service2026-07-26327517821.8 KB
Audits

Accept evidence for an information request

Accepts evidence for an information request, confirming that all submitted evidence meets audit requirements. This action changes the request's approvalStatus to an approved state and creates an activity log entry.

Acceptance workflow:

  1. Auditor reviews submitted evidence
  2. If evidence is satisfactory, auditor calls this endpoint
  3. Request status changes to approved state and is considered complete for this audit cycle

Use this endpoint when:

  • All required evidence has been submitted
  • Evidence quality meets audit standards
  • Evidence addresses all specified framework codes
  • No additional information is needed

Rate limit: 50 requests / minute.

post/audits/{auditId}/information-requests/{requestId}/accept-evidence

Path parameters

auditIdstring required
requestIdstring required

Request body

auditorEmailstring required

Email of the auditor accepting the evidence. Must match an existing Vanta user who belongs to the audit firm making the API request.

Response

Ok

idstring required

The unique identifier for the information request within Vanta's system. This is the primary identifier used in all API endpoints. Format: ObjectId as a string (e.g., "6890e473dce1da5d8406f5e7")

uniqueIdstring required

External unique ID to prevent duplicates across different audit systems. Used for idempotency when syncing data between external audit management systems and Vanta. Unlike id, this value is provided by the external system.

additionalControlIdsstring[] required

Additional control IDs beyond those automatically mapped from framework codes. Allows manual association with specific controls when automatic mapping is insufficient. Each ID should reference a valid control in your audit framework.

approvalStatus'NEEDS_EVIDENCE' | 'READY_FOR_AUDIT' | 'AUDITOR_APPROVED' | 'AUDITOR_FLAGGED' required

Current approval status of the information request, tracking its lifecycle through the audit process.

The status progresses through the workflow: initial state → awaiting review → approved or flagged. Status can move between awaiting review and flagged states as evidence is reviewed and resubmitted.

cadence'ANNUALLY' | 'BIANNUALLY' | 'MONTHLY' | 'QUARTERLY' required

Frequency cadence for the information request, indicating how often it recurs.

frameworkCodesstring[] required

The framework codes this request addresses. Links the request to specific compliance requirements. Can be an empty array if no framework codes are associated. These codes correspond to standards like SOC 2, ISO 27001, etc.

descriptionstring nullable required

Detailed description explaining what evidence is needed and why. Should provide clear instructions to help the customer understand what to submit.

dueDatestring date-time nullable required

The deadline by which the customer must fulfill this request. Null if no specific deadline is set. Format: ISO 8601 UTC timestamp.

evidenceCaptureDatestring date-time nullable required

The earliest date for which evidence should be captured. Evidence dated before this date may not be accepted. Null if not restricted. Format: ISO 8601 UTC timestamp.

requestIdstring nullable required

Non-unique external reference ID for this request. Unlike uniqueId which must be unique, requestId is for display/reference purposes only (e.g., "REQ-123"). Null if not provided.

requestType'POINT_IN_TIME' | 'POPULATION' | 'SAMPLE' required

Type of information request, defining what scope of evidence is needed.

  • POINT_IN_TIME: Evidence for a specific moment (e.g., current state of a policy)
  • POPULATION: Evidence covering all items in a category (e.g., all employees)
  • SAMPLE: Evidence for a representative sample (e.g., 10 random customer records)
titlestring required

Short, descriptive title summarizing what is being requested.

creationDatestring date-time required

Timestamp when the request was created in the system. Format: ISO 8601 UTC timestamp.

modificationDatestring date-time required

Timestamp when the request was last modified. Format: ISO 8601 UTC timestamp.

deletionDatestring date-time nullable required

Timestamp when the request was soft-deleted. Null if the request has not been deleted. Soft deletes allow retaining history while hiding the request from normal operations. Format: ISO 8601 UTC timestamp.