---
title: "Update identity verification in batch"
method: PUT
path: "/v2/identity_verification"
tags: ["Identity Verification"]
---

# Update identity verification in batch

`PUT /v2/identity_verification`

## Request body

- IdentityVerification[]
  - `related_company_id` string — Unique identifier of the related company entity (used for business contexts). Only one of related_company_id and related_person_id can be specified.
  - `related_person_id` string — Unique identifier of the related person entity (used for retail contexts or when a person is the subject). Only one of related_company_id and related_person_id can be specified.
  - `timestamp` string, date-time, required — When the identity verification completed, in ISO 8601 format. Use the timestamp from your verification provider's response.
  - `verification_id` string, required — Unique identifier for an identity verification. This is the primary identifier for an identity verification and should be unique across all identity verifications. Updates to an identity verification should be made using this identifier. This can reference: - Your internal verification record ID - The original provider's verification ID (optionally with a prefix) - Any unique identifier that allows traceability to the original data source
  - `verification_overall_outcome` string — Result of IDV screening returned from provider
  - `verification_provider` string, required — Which verification provider verified those attributes for the person or company. If this is an internal process, mention the name of your company.
  - `verification_type` 'DOCUMENT_MATCH' | 'DATABASE_MATCH' | 'MANUAL_VERIFICATION'
  - `verified_data` object[], required — Array of individual data points verified in this verification event only. Each item represents a specific piece of information (name, DOB, address, etc.) that was checked during this particular verification. Do not include: - Data points from other verification events - Aggregated results from multiple verifications - Data that wasn't actually verified in this specific check Example: If this verification only checked name and DOB, only include those two items in the array, even if other data points were verified in previous or separate verification events.
    - `is_manually_verified` boolean — Indicates whether the data was manually verified by an internal team or trusted individual. This is true when the verification process involves human intervention rather than an automated system, for example when verifying a document.
    - `is_matched_externally` boolean — Specifies whether the data was verified by comparing it with an external source, such as a third-party verification provider, external database, or through documentary verification (e.g., matching documents against regulatory standards).
    - `outcome` string, required — The result of the verification for this data being verified
    - `type` string, required — The type of data being verified for the person or company
    - `value` string — The actual data that was verified, such as a name or ID number.

## Response `200`

Identity verifications updated successfully

- WriteOperationResponse
  - `message` string, required — Provides additional information about the operation result.
  - `organization_id` string, required — The organization ID for which the operation was performed.
  - `success` boolean, required — Indicates if the write operation was successful.
  - `write_count` integer, required — The number of records written to the database.

## Other responses

- `400` — Invalid identity verification data
- `401` — Unauthorized request
- `404` — Identity verification not found
- `429` — Rate limit exceeded
- `500` — Server error
- `default` — General error

---

[API](https://skmtc.dev/cable/apis/cable-api.md) · [All operations](https://skmtc.dev/cable/apis/cable-api/llms.txt) · [OpenAPI document](https://skmtc-service-production.skmtc.workers.dev/v1/apis/cable/cable-api/revisions/3222cd28dba5/schema)
