--- title: "Append Batch Create Check Requests" method: POST path: "/v1alpha2/operations/{operation}:appendBatchCreateCheckRequests" tags: ["ClientService"] --- # Append Batch Create Check Requests `POST /v1alpha2/operations/{operation}:appendBatchCreateCheckRequests` ## Request - Base URL: `https://api.thirdfort.dev/client/api` - URL: `https://api.thirdfort.dev/client/api/v1alpha2/operations/{operation}:appendBatchCreateCheckRequests` - Auth: HTTP bearer Appends more check-creation entries to a not-started batch-create-checks operation. ## Path parameters - `operation` string, required ## Request body - ClientServiceAppendBatchCreateCheckRequestsBody: Request message for [ClientService.AppendBatchCreateCheckRequests](#/operations/ClientService_AppendBatchCreateCheckRequests). - `requests` CreateCheckRequest[], required: Required. Additional check-creation entries. A maximum of 1000 entries may be included in a single request, and every entry must use the same template as the operation. - `parent` string, required: Required. The parent resource where the check will be created. Format: `organizations/{organization}/teams/{team}`. The check will be owned by this team and inherit its access controls. - `check` Check, required: A [Check](#/schemas/Check) represents an execution of a compliance workflow defined by a CheckTemplate. Checks perform due diligence and verification processes on one or more [Subjects](#/schemas/Subject) according to the template's configuration. Most checks operate on a single subject (e.g., identity verification for an individual), but some may involve multiple subjects when a comprehensive view is required (e.g., source of funds verification for a transaction involving multiple parties). Checks have a lifecycle that includes creation, execution, and completion phases. They can be in ACTIVE state while processing, INACTIVE when waiting for input or completed, CANCELLED if terminated, or DELETED once soft-deleted. - `name` string: The unique resource name of the check. Format: `organizations/{organization}/teams/{team}/checks/{check}`. This field is system-generated and immutable. - `displayName` string: Required. Human-readable name for the check, used for identification in user interfaces. Examples: "Address Verification for Purchase of 58 Goodwood Park Road" or "Annual Identity Check". For standalone checks, this name is also displayed to consumers during the verification process. - `clientReference` string, required: Client-provided reference for correlating the check with external systems. While uniqueness is recommended for easier tracking, it is not enforced by the system. This field is not used by Thirdfort for check identification but can be used for client-side correlation and reporting. - `state` 'STATE_UNSPECIFIED' | 'ACTIVE' | 'INACTIVE' | 'CANCELLED' | 'DELETED': The operational state of the check, indicating its current phase in the compliance workflow. - STATE_UNSPECIFIED: Default value. This value is unused. - ACTIVE: The check is actively processing, performing analysis, waiting for data from subjects or third-party providers, or scheduled to run additional verification steps. Active checks may transition back to INACTIVE when processing completes or when waiting for external input. They can be reactivated through various triggers such as ongoing monitoring events or finding reviews. - INACTIVE: The check is not currently performing analysis or waiting for external data. This state indicates the check has completed its current processing cycle and is awaiting further action. Checks can transition from INACTIVE to ACTIVE through actions like enabling ongoing monitoring, reviewing findings, or receiving new data. - CANCELLED: The check has been permanently cancelled and will no longer perform any processing. This is a terminal state - cancelled checks cannot be reactivated or moved to any other state. All ongoing operations are stopped and no further analysis will occur. - DELETED: The check has been soft-deleted and is pending permanent removal. It can be undeleted before the retention period expires, after which it will be permanently purged. - `createTime` string, date-time: The timestamp when the check was created. This field is set automatically when the check is first created and never changes. - `updateTime` string, date-time: The timestamp when the check was last modified. This includes system-driven updates such as state changes, new findings, or the creation of new check summaries. It also updates when users interact with the check. - `template` string, required: The resource name of the CheckTemplate that defines the compliance workflow for this check. The template determines what verification steps will be performed and how results are processed. - `params` union - IdentityVerificationCheckParams: The input parameters required to perform an IdentityVerificationCheck. This check is used to verify the identity of an individual and encompassed both Enhanced NFC ID and Original ID products as the former is essentially just the latter but with NFC requested before trying standard document scans. - `@type` string: Type URL identifying this message type. Must be `type.googleapis.com/thirdfort.client.checks.type.v1alpha2.IdentityVerificationCheckParams`. - `subject` IdentityVerificationCheckParamsClientProvidedSubjectData: Check [Subject](#/schemas/Subject) data provided by the client when creating the [Check](#/schemas/Check). - `givenName` string: Required. The given name of the [Subject](#/schemas/Subject). - `familyName` string: Required. The family name of the [Subject](#/schemas/Subject). - `phoneNumber` string: Required. The phone number of the [Subject](#/schemas/Subject). Must be in E.164 format (e.g., +447700900123): a leading `+` and no spaces. - `email` string: Optional. The email address of the [Subject](#/schemas/Subject). - `industry` string: The industry that the check is being performed in. This is informational only and does not affect the check itself. Free-form text. - `passportNfcPreference` 'PASSPORT_NFC_PREFERENCE_UNSPECIFIED' | 'OPTIONAL' | 'SKIP': An indication of how the presence, or not, of NFC should be handled when the passport is provided as evidence. If set to OPTIONAL, NFC will be attempted first but if it fails, a non-NFC method will be used. This represents a world where Enhanced NFC ID is selected, but Original ID is allowed as a fallback. If set to SKIP, NFC will not be used and only non-NFC methods will be used. This represents a world where Original ID is explicitly selected. Required: PASSPORT_NFC_PREFERENCE_UNSPECIFIED is rejected. OPTIONAL requires the KYC_IDV_ENHANCED entitlement; SKIP requires KYC_IDV_ORIGINAL. - `requireProofOfAddressDocument` boolean: Whether the consumer must supply a proof-of-address document. Defaults to false. Requires the KYC_PROOF_OF_ADDRESS entitlement. - `requireProofOfOwnershipDocument` boolean: Whether the consumer must supply a proof-of-ownership document. Defaults to false. Requires the KYC_PROOF_OF_OWNERSHIP entitlement. - `requireSourceOfFundsQuestionnaire` boolean: Whether the consumer completes the full Source of Funds questionnaire. Defaults to false. Mutually exclusive with require_banking_data; setting both is rejected. Requires the SOF_QUESTIONNAIRE entitlement. - `enableOngoingMonitoring` boolean: Whether ongoing monitoring is enabled when the check is created. Defaults to false. Requires the AML_ONGOING_MONITORING entitlement. - `persona` string: The persona of the subject undergoing the check. Used to determine which task flow to create in the Consumer API. Valid values: "seller", "purchaser", "giftor", "propertyOther", "landlord", "tenantOccupantGuarantor" - `internationalAddressVerificationConsent` boolean: Indicates whether the client has given consent for international address verification. Requires the INTERNATIONAL_ADDRESS_VERIFICATION entitlement. - `enableOcr` boolean: Whether OCR-based extraction is enabled for uploaded documents. Controlled by the org-level "sof-ocr" feature flag. - `requireCcjInsolvency` boolean: Whether CCJ and insolvency check is required. Defaults to false. Requires the KYC_CCJ_INSOLVENCY entitlement. - `requireBankingData` boolean: Whether to request bank statements from the consumer as a standalone add-on to the ID check, without requiring a full Source of Funds flow. Defaults to false. Mutually exclusive with require_source_of_funds_questionnaire; setting both is rejected. Requires the BANKING_DATA entitlement. - `bankHistoryTimeframeMonths` integer: The bank statement history period in months, snapshotted from the firm's "bank-history-timeframe" setting at check creation. Downstream services (consumer task params, TrueLayer fetch) read this value rather than the firm setting, so post-creation changes to the firm setting do not affect this check. Falls back to 6 months when no firm setting is configured. Allowed values mirror the firm setting: 3, 6, 12. Zero means "unset" — the server resolves the value from the firm setting in that case. - `sourceOfFundsMode` 'SOURCE_OF_FUNDS_MODE_UNSPECIFIED' | 'FULL' | 'BASIC': This field exists so that Temporal histories for checks created between 2026-07-10 and this field's retirement still deserialize correctly. Delete once CDD-7615 has shipped. - `consumerPayment` ConsumerPayment: A payment the consumer makes in the Thirdfort app before the rest of the check's tasks are created. The consumer pays on a hosted payment page; once the payment is taken, their other tasks appear. The organization must have the `consumer-payments` feature flag enabled: a check that asks for a payment without it is rejected with FAILED_PRECONDITION. - `amount` Money: Represents an amount of money with its currency type. - … - `description` string: What the consumer is paying for, shown to them in the app and on the payment page, for example "ID check for your house purchase". A generic description is used when empty. - ClientOnlyVerificationCheckParams: The input parameters required to perform a ClientOnlyVerificationCheck. This check is used to verify the identity of an individual when the person is not in the flow. - `@type` string: Type URL identifying this message type. Must be `type.googleapis.com/thirdfort.client.checks.type.v1alpha2.ClientOnlyVerificationCheckParams`. - `subject` ProvidedSubjectData: A summarization of data that was provided by the initiator of the [Check](#/schemas/Check) in relation to the [Subject](#/schemas/Subject) of the [Check](#/schemas/Check). - `givenName` string: The given name of the [Subject](#/schemas/Subject). In the UK, this is also known as the "first name". - `otherNames` string: The other names of the [Subject](#/schemas/Subject). In the UK, this is also known as the "middle names". - `familyName` string: The family name of the [Subject](#/schemas/Subject). In the UK, this is also known as the "last name" or "surname". - `yearOfBirth` integer: The year of birth of the [Subject](#/schemas/Subject). - `address` Address: A structured representation of an address. The format of this is designed to accomodate for address formats across the world, but may not be suitable for all countries currently. - … - `dateOfBirth` TypeDate: Represents a calendar date with year, month, and day components. - … - `residenceFatfList` 'FATF_LIST_UNSPECIFIED' | 'BLACK_LIST' | 'GREY_LIST' | 'NOT_LISTED': The FATF list classification of the country in `address.country_code`, resolved and locked at check time (CDD-6933). Persisting it here means a later FATF plenary update cannot retroactively reclassify this check: the residential-address country's FATF designation stays as it was when the check ran, consistent with how source-of-funds locks its own classification. - `address` Address: A structured representation of an address. The format of this is designed to accomodate for address formats across the world, but may not be suitable for all countries currently. - `subBuilding` string: Optional. A more granular indication of the address within the referenced building. Example: Flat 8, Floor 1 - `buildingNumber` string: Optional. The street number of the address's building. Example: 8 One of building_number or building_name must be provided. - `buildingName` string: Optional. The street name of the address's building. Example: Highroyd One of building_number or building_name must be provided. - `street` string: Optional. The street of the address. Example: High Street Must be provided if building_number is set. - `subLocality` string: Optional. A more granular indication of the address within the referenced locality. This can be a neighbourhood, borough or district. Example: Southwark - `locality` string: Optional. Generally refers to the city/town portion of the address such as a an US city, IT commune or UK post town. Example: London - `administrativeArea` string: Optional. Highest administrative subdivision which is used for addresses in the country. This could be a state, province, county, etc, depending on the country. This is not used used in all countries (e.g: Switzerland). Example: Greater London - `postalCode` string: Optional. Postal code for the address. Not all countries use or require postal codes. For those that do, country specific validation will be applied. Example: SE1 1AA - `countryCode` string: Required. The ISO 3166-1 alpha country code of the address. Example: GBR - `company` string: Optional. Company name - some addresses are associated with company entities. Example: Radnor House Nursing and Residential Home - `requireAddressVerification` boolean: Whether the subject's address is verified in addition to screening. Defaults to false. When true, `subject.date_of_birth` must be a complete, valid calendar date and the additional `address` fields listed above become required. Selects the entitlement this check requires: AML_LITE_SCREENING when true, AML_STANDALONE_SCREENING when false. - `relationshipType` string: The relationship type of the subject, is this a client of the client or is the check for another purpose. Free-form text. - `enableOngoingMonitoring` boolean: Whether ongoing monitoring is enabled when the check is created. Defaults to false. - `internationalAddressVerificationConsent` boolean: Indicates whether the client has given consent for international address verification. Requires the INTERNATIONAL_ADDRESS_VERIFICATION entitlement. - `requireCcjInsolvency` boolean: Whether CCJ and insolvency check is required. Defaults to false. Requires require_address_verification to be true; setting it alone is rejected. Requires the KYC_CCJ_INSOLVENCY entitlement. - KYBVerificationCheckParams: The input parameters required to perform a KYB (Know Your Business) verification check. This check is used to verify the legitimacy and compliance of a business entity, including company summary, beneficial ownership, sanctions screening, and document retrieval. - `@type` string: Type URL identifying this message type. Must be `type.googleapis.com/thirdfort.client.checks.type.v1alpha2.KYBVerificationCheckParams`. - `subject` KYBVerificationCheckParamsClientProvidedSubjectData, required: Check subject data provided by the client when creating the Check. This contains only the identifying information needed to look up the company. - `dunsNumber` string, required: The DUNS number The expectation is that the client has already performed a search and has retrieved the DUNS number. - `name` string, required: The legal name of the business. - `jurisdiction` string, required: The jurisdiction of the business as an ISO 3166-1 alpha-2 country code. Example: "GB" for United Kingdom, "DE" for Germany. - `registrationNumber` string: The primary registration number of the business (e.g., company number). This can be empty for some jurisdictions other than GB. - `registrationNumberType` string: The registration number type. - `state` string: Optional. The state or region within the jurisdiction. For US companies, this is the 2-character state code (e.g., "CA", "NY"). - `initialDocumentRetrieval` string[]: The documents to be retrieved as part of the kyb check. Each must be listed for the subject's jurisdiction and state by its KYBVerificationRegion; any other value returns INVALID_ARGUMENT. - `packageType` 'KYB_PACKAGE_TYPE_UNSPECIFIED' | 'KYB_LITE' | 'KYB', required: The type of KYB package requested - `enableOngoingMonitoring` boolean: Whether ongoing monitoring should be enabled for this KYB check, so the business is re-screened against updated data after the initial check. - SourceOfFundsCheckParams: The input parameters required to perform a standalone SourceOfFundsCheck. This check is used to verify the source of funds for an individual without requiring identity verification. Always requires the SOF_QUESTIONNAIRE entitlement on the team. - `@type` string: Type URL identifying this message type. Must be `type.googleapis.com/thirdfort.client.checks.type.v1alpha2.SourceOfFundsCheckParams`. - `subject` SourceOfFundsCheckParamsClientProvidedSubjectData: Check [Subject](#/schemas/Subject) data provided by the client when creating the [Check](#/schemas/Check). - `givenName` string: Required. The given name of the [Subject](#/schemas/Subject). - `familyName` string: Required. The family name of the [Subject](#/schemas/Subject). - `phoneNumber` string: Required. The phone number of the [Subject](#/schemas/Subject). Must be in E.164 format (e.g., +447700900123): a leading `+` and no spaces. - `email` string: Optional. The email address of the [Subject](#/schemas/Subject). - `industry` string: The industry that the check is being performed in. This is informational only and does not affect the check itself. Free-form text. - `persona` string: The persona of the subject undergoing the check. Used to determine which task flow to create in the Consumer API. Valid values: "seller", "purchaser", "giftor", "propertyOther", "landlord", "tenantOccupantGuarantor" - `requireProofOfAddressDocument` boolean: Whether the consumer must supply a proof-of-address document. Defaults to false. When true, the resulting [CheckSummary](#/schemas/CheckSummary) includes `address_verification_check_result`. Requires the KYC_PROOF_OF_ADDRESS entitlement. - `enableOcr` boolean: Whether OCR-based extraction is enabled for uploaded documents. Controlled by the org-level "sof-ocr" feature flag. - `bankHistoryTimeframeMonths` integer: The bank statement history period in months, snapshotted from the firm's "bank-history-timeframe" setting at check creation. Downstream services (consumer task params, TrueLayer fetch) read this value rather than the firm setting, so post-creation changes to the firm setting do not affect this check. Falls back to 6 months when no firm setting is configured. Allowed values mirror the firm setting: 3, 6, 12. Zero means "unset" — the server resolves the value from the firm setting in that case. - `consumerPayment` ConsumerPayment: A payment the consumer makes in the Thirdfort app before the rest of the check's tasks are created. The consumer pays on a hosted payment page; once the payment is taken, their other tasks appear. The organization must have the `consumer-payments` feature flag enabled: a check that asks for a payment without it is rejected with FAILED_PRECONDITION. - `amount` Money: Represents an amount of money with its currency type. - … - `description` string: What the consumer is paying for, shown to them in the app and on the payment page, for example "ID check for your house purchase". A generic description is used when empty. - `sourceOfFundsMode` 'SOURCE_OF_FUNDS_MODE_UNSPECIFIED' | 'FULL' | 'BASIC': This field exists so that Temporal histories for checks created between 2026-07-10 and this field's retirement still deserialize correctly. Delete once CDD-7615 has shipped. - `relatedSubjects` SubjectRelation[]: The subjects undergoing due diligence in this check. Most checks involve a single subject (e.g., identity verification for one individual), but some may involve multiple subjects when a comprehensive view is required (e.g., source of funds verification for a transaction with multiple contributing parties). This field is automatically populated based on the check's template and parameters. The subjects may be explicitly specified in the parameters or derived through the check's internal logic. - `relationship` string, required: The relationship between the [Subject](#/schemas/Subject) and the other resource. This is string typed as the nature of the relationship is arbitrary and can vary widely by sector. - `subject` Subject, required: A [Subject](#/schemas/Subject) is an entity that is undergoing due diligence, or related to a [Check](#/schemas/Check) where due diligence is being performed. - `name` string - `individual` Individual: An [Individual](#/schemas/Individual) represents a named, single person. - `title` string: The title of the [Individual](#/schemas/Individual), e.g: Mr, Mrs, Dr etc. - `givenName` string: The given name of the [Individual](#/schemas/Individual). This terminology is used instead of "first name" to better accomodate for cultures where the given name may not be written first. - `familyName` string: The family name of the [Individual](#/schemas/Individual). This terminology is used instead of "last name" to better accomodate for cultures where the family name may not be written last. - `otherNames` string: The other names of the [Individual](#/schemas/Individual). In the UK, this is also known as the "middle names". - `email` string: RFC 5322 compliant email address of the Individual. - `phoneNumber` string - `dateOfBirth` TypeDate: Represents a calendar date with year, month, and day components. - … - `business` Business: A [Business](#/schemas/Business) represents a company or other legal entity. - `jurisdiction` string: The jurisdiction of the business as an ISO 3166-1 alpha-2 country code. Example: "GB" for United Kingdom, "DE" for Germany. - `name` string: The legal name of the business as registered with the relevant authority. - `registrationNumber` string: The registration number of the business. - `registrationNumberType` string: The registration number type. - `dunsNumber` string: The D&B DUNS number for the business. - `state` string: The state or region within the jurisdiction, if applicable. For US companies, this is the 2-character state code (e.g., "CA", "NY"). - `owner` string: Optional resource name of the entity that owns this check. Checks are not required to have an owner, but when present, this establishes a hierarchical relationship (e.g., a parent check that spawns child checks). A caller-supplied owner that names a check must be an existing, non-deleted check in the same team, and never a set hub: set membership is assigned by the server (LinkCheck, CreateCheckSet), not by setting owner. - `creator` string: The resource name of the [User](#/schemas/User) who created this check. For checks that are owned by another resource, this refers to the user who created the owning resource rather than the check itself. - `deleteTime` string, date-time: The time at which the [Check](#/schemas/Check) was soft-deleted. - `purgeTime` string, date-time: The time at which the [Check](#/schemas/Check) will be hard-deleted from the system. - `ongoingMonitoring` OngoingMonitoring: Describes the settings and status of an Ongoing Monitoring component. While `enabled` is true the subscription renews itself automatically: at `active_until` a new period begins and is billed, with no action required to keep monitoring running. To stop it renewing, call [ClientService.SetOngoingMonitoring](#/operations/ClientService_SetOngoingMonitoring) with `enabled` set to false. - `enabled` boolean: True if Ongoing Monitoring is currently running for this check. This is the only field that says whether the check is being monitored; disabling takes effect immediately rather than at `active_until`. - `activeUntil` string, date-time: The end of the current billing period. While `enabled` is true this is the datetime at which the subscription automatically renews for another period and is billed again -- not a datetime at which monitoring stops. This field is not cleared when Ongoing Monitoring is disabled, so it may hold a future datetime for a check that is no longer monitored. Read `enabled`, not `active_until`, to determine whether monitoring is running. Unset if no subscription has ever been activated for this check. - `notificationRecipient` string: The recipient who should receive notifications for this [Check](#/schemas/Check). Usually a [User](#/schemas/User), but may also be an integration resource name (`partners/{partner}/integrations/{id}` or `organizations/{org}/integrations/{id}`) when the check was created by an integration actor — in that case notifications are delivered to the integration's webhook rather than by email. May be set at creation to nominate a recipient other than the creator; a nominated recipient must currently be a [User](#/schemas/User) in the same organization as the check with permission to view checks in its team (integrations cannot be nominated explicitly yet). When omitted at creation, this defaults to the actor that created the [Check](#/schemas/Check), which may itself be an integration. The resource_reference is a wildcard because the field is polymorphic (a User or an integration, as with an owner reference); nomination via the API is nonetheless currently restricted to a User. - `ownerLabel` string: Optional human-readable label for the owner of this check. This field provides a display name or description for the owner resource, used in user interfaces such as links back to the owning check. For example, when a KYC check is created from a KYB check, this field would contain the display name of the KYB check to show in the UI. This field is only meaningful when the owner field is set. - `relationships` CheckRelationship[]: Optional Relationships that link this [Check](#/schemas/Check) to other [Checks](#/schemas/Check). Each entry describes a directed link from a parent check to this check (the child), and is only stored on the child side of the relationship. Linked checks must belong to the same organization and team. - `relationshipType` 'CHECK_RELATIONSHIP_TYPE_UNSPECIFIED' | 'KYB_TO_KYC' | 'KYB_TO_KYB' | 'KYC_TO_KYB' | 'SOF_TO_SOF_CO_PURCHASER' | 'SOF_TO_SOF_GIFTOR' | 'ID_TO_SOF' | 'ID_TO_ID_CO_PURCHASER' | 'ID_TO_ID_GIFTOR', required: The nature of a [CheckRelationship](#/schemas/CheckRelationship). relationship entry is stored on the child [Check](#/schemas/Check) and the related check referenced by the entry is the parent. - CHECK_RELATIONSHIP_TYPE_UNSPECIFIED: Default value. This value is unused. - KYB_TO_KYC: A KYC check that was initiated from a parent KYB check, typically for a PSC, UBO, or officer of the business being verified. - KYB_TO_KYB: A KYB check that was initiated from a parent KYB check, typically representing a subsidiary or other entity in a group structure. - KYC_TO_KYB: A KYB check that was initiated from a parent KYC check, typically when an individual being verified is linked to a business that also requires verification. - SOF_TO_SOF_CO_PURCHASER: A Source of Funds check that is linked to another Source of Funds check as a co-purchaser on the same transaction. - SOF_TO_SOF_GIFTOR: A Source of Funds check for a giftor that was initiated from a parent Source of Funds check for the purchaser receiving the gift. - ID_TO_SOF: A Source of Funds check that was added to an existing identity verification check (for example, a standalone SOF or banking data check layered on afterwards). - ID_TO_ID_CO_PURCHASER: An identity check that is linked to another identity check as a co-purchaser on the same transaction (an ID-only co-purchaser set, with no Source of Funds component). - ID_TO_ID_GIFTOR: An identity check for a giftor that is linked to the identity check of the purchaser receiving the gift (an ID-only set: identity is verified, the gifted funds are not evidenced). - `relatedCheck` string, required: The resource name of the related (parent) [Check](#/schemas/Check). Format: `organizations/{organization}/teams/{team}/checks/{check}`. - `reference` string: Optional pointer to the specific data point inside the related (parent) [Check](#/schemas/Check) that motivated this relationship. Free-form string, but typically the resource name of a related check, a [Finding](#/schemas/Finding) within the related check, or an entry inside a finding (such as a member of a group finding) extended with a caller-defined suffix. Examples: - `organizations/{organization}/teams/{team}/checks/{check}` - `organizations/{organization}/teams/{team}/checks/{check}/findings/{finding}` - `organizations/{organization}/teams/{team}/checks/{check}/findings/{finding}/members/{member}` For example, on a KYB-to-KYC relationship this may carry the finding (and member id) representing the PSC, UBO, or officer that prompted the child KYC check. - `createTime` string, date-time: The time at which the relationship was established. - `creator` string: The [User](#/schemas/User) who established the relationship. - `overallRecommendation` 'RECOMMENDATION_UNSPECIFIED' | 'CLEAR' | 'CONSIDER' | 'FAIL' | 'UNSUPPORTED_BY_PROVIDER' | 'NOT_APPLICABLE' | 'NOT_SUCCESSFUL': - RECOMMENDATION_UNSPECIFIED: Default value, used when no recommendation has been determined. - CLEAR: The associated result has no concerning issues according to our systems. - CONSIDER: The associated result has some anomalies that would be investigated by the client, but may be explainable. E.g: Name mismatch between entered data and what was pulled from documents. - FAIL: The associated result has anomalies that are serious and unlikely to be explainable. E.g: The supplied identity document is a clear forgery. - UNSUPPORTED_BY_PROVIDER: A recommendation could not be provided as providing the associated result is not supported by the selected provider. - NOT_APPLICABLE: A recommendation could not be provided as the associated result is not applicable to this check's configuration. - NOT_SUCCESSFUL: The associated result is a definite unsuccessful outcome rather than a judgement left to the client. Distinct from CONSIDER, which asks the client to weigh an anomaly, and from FAIL, which reports that the control itself broke. E.g: a Right to Rent check where no acceptable document was declared. - `compositeStatus` 'CHECK_COMPOSITE_STATUS_UNSPECIFIED' | 'CHECK_COMPOSITE_STATUS_SENT_TO_CONSUMER' | 'CHECK_COMPOSITE_STATUS_IN_PROGRESS' | 'CHECK_COMPOSITE_STATUS_PROCESSING' | 'CHECK_COMPOSITE_STATUS_COMPLETE' | 'CHECK_COMPOSITE_STATUS_READY_FOR_REVIEW' | 'CHECK_COMPOSITE_STATUS_REVIEW_REQUESTED' | 'CHECK_COMPOSITE_STATUS_REVIEW_APPROVED' | 'CHECK_COMPOSITE_STATUS_REVIEW_REJECTED' | 'CHECK_COMPOSITE_STATUS_CANCELLED': At-a-glance lifecycle status blending Check.state, Check.overall_recommendation, and review-task progress. Used by portal surfaces in place of the raw state for rendering and for filtering the check list. Defined at file scope (not nested under Check) to avoid enum-value collisions with Check.State (e.g. CANCELLED). Values are ordered by the progression of a check through its lifecycle. SENT_TO_CONSUMER and PROCESSING are not currently emitted: while a check is ACTIVE the server uses IN_PROGRESS for the whole span. Callers should still handle these values, as the server may narrow ACTIVE into SENT_TO_CONSUMER → IN_PROGRESS → PROCESSING in future releases without a breaking schema change. - CHECK_COMPOSITE_STATUS_UNSPECIFIED: Default value. Set when the composite has not yet been computed — for example on a freshly created check before any workflow activity has run, or for terminal states (DELETED) we do not render. - CHECK_COMPOSITE_STATUS_SENT_TO_CONSUMER: The check is ACTIVE and waiting for the consumer to start their journey — no consumer task has left NOT_STARTED yet. Not currently emitted; see the enum-level comment. - CHECK_COMPOSITE_STATUS_IN_PROGRESS: The check is actively processing — waiting on consumer input, supplier calls, or backend orchestration. Set while Check.state is ACTIVE. - CHECK_COMPOSITE_STATUS_PROCESSING: The check is ACTIVE and the consumer has finished their journey; backend orchestration is still finalising the result. Not currently emitted; see the enum-level comment. - CHECK_COMPOSITE_STATUS_COMPLETE: Processing is complete and the overall recommendation came back CLEAR, so no reviewer action is expected. Set when state is INACTIVE, no review task is active, and the recommendation is CLEAR. - CHECK_COMPOSITE_STATUS_READY_FOR_REVIEW: Processing is complete and the recommendation surfaces items that would benefit from human review, but no review task has been opened yet. - CHECK_COMPOSITE_STATUS_REVIEW_REQUESTED: A review task is outstanding (PENDING or IN_PROGRESS). Wins over the underlying recommendation — a pending review takes precedence over a CLEAR recommendation because the reviewer may be looking at supplementary context. - CHECK_COMPOSITE_STATUS_REVIEW_APPROVED: The latest non-cancelled review task completed with an APPROVED decision. - CHECK_COMPOSITE_STATUS_REVIEW_REJECTED: The latest non-cancelled review task completed with a REJECTED decision. - CHECK_COMPOSITE_STATUS_CANCELLED: The check has been cancelled and will not process further. - `overallRiskSeverity` 'RISK_INDICATOR_SEVERITY_UNSPECIFIED' | 'RISK_INDICATOR_SEVERITY_CRITICAL' | 'RISK_INDICATOR_SEVERITY_HIGH' | 'RISK_INDICATOR_SEVERITY_MEDIUM' | 'RISK_INDICATOR_SEVERITY_LOW': The severity assigned to a [RiskIndicator](#/schemas/RiskIndicator) by the rule that produced it. Stored at full granularity in the data model even when the UI surfaces a narrower set of tiers, so the rendering can evolve without re-deriving stored values. Values are ordered such that lower numeric value indicates higher severity (CRITICAL = 1, LOW = 4); use the textual ordering CRITICAL > HIGH > MEDIUM > LOW when comparing rather than relying on numeric `<` / `>`. - RISK_INDICATOR_SEVERITY_UNSPECIFIED: Default value. Set on placeholder ("no-verdict") revisions or when the computed verdict has lapsed. - RISK_INDICATOR_SEVERITY_CRITICAL: The highest severity (e.g. active sanction match, active insolvency, document fraud). Emitted by V1 rules and surfaced as the check's peak severity; not yet wired to any automatic escalation. - RISK_INDICATOR_SEVERITY_HIGH: The indicator requires reviewer attention with priority over standard findings (e.g. senior PEP, regulatory warning, active CCJ). - RISK_INDICATOR_SEVERITY_MEDIUM: The indicator warrants review but at standard priority. - RISK_INDICATOR_SEVERITY_LOW: Informational; reviewer attention is optional. - `onBehalfOf` string: Optional resource name of the [User](#/schemas/User) on whose behalf this check was created. May be set at creation only when the caller is an integration acting for a user; requests from user or system actors that set this field are rejected with INVALID_ARGUMENT. The check then records both the integration that created it (creator) and the user it was created for. Must be a non-deleted [User](#/schemas/User) in the same organization as the check. Empty when the check was not created on a user's behalf. Immutable after creation. - `matter` string - `requestId` string: Optional caller-scoped idempotency key (a UUID is recommended). Resending the same request with the same request_id returns the already-created check instead of a duplicate, completing its set link if needed; if no check exists for the key, the request is rejected. Reusing a key with a changed payload is a misuse. Honoured on CreateCheck only - batch and set entries must not set it. Sent as a query parameter on the REST surface (`?requestId=...`), since the request body maps to `check`; in the body it is silently ignored. - `matter` string ## Response `200` A successful response. - GooglelongrunningOperation: Represents a long-running operation that is the result of a network API call. - `name` string: The server-assigned name, which is only unique within the same service that originally returns it. If you use the default HTTP mapping, the `name` should be a resource name ending with `operations/{unique_id}`. - `metadata` ProtobufAny: Contains an arbitrary serialized protocol buffer message along with a type URL that identifies the message type. - `@type` string: A URL/resource name that uniquely identifies the type of the serialized protocol buffer message. This string must contain at least one "/" character. The last segment of the URL's path must represent the fully qualified name of the type (as in `path/google.protobuf.Duration`). The name should be in a canonical form (e.g., leading "." is not accepted). In practice, teams usually precompile into the binary all types that they expect it to use in the context of Any. However, for URLs which use the scheme `http`, `https`, or no scheme, one can optionally set up a type server that maps type URLs to message definitions as follows: * If no scheme is provided, `https` is assumed. * An HTTP GET on the URL must yield a google.protobuf.Type value in binary format, or produce an error. * Applications are allowed to cache lookup results based on the URL, or have them precompiled into a binary to avoid any lookup. Therefore, binary compatibility needs to be preserved on changes to types. (Use versioned type names to manage breaking changes.) Note: this functionality is not currently available in the official protobuf release, and it is not used for type URLs beginning with type.googleapis.com. Schemes other than `http`, `https` (or the empty scheme) might be used with implementation specific semantics. - `done` boolean: If the value is `false`, it means the operation is still in progress. If `true`, the operation is completed, and either `error` or `response` is available. - `error` GooglerpcStatus: The `Status` type defines a logical error model that is suitable for different programming environments, including REST APIs and RPC APIs. It is used by [gRPC](https://github.com/grpc). Each `Status` message contains three pieces of data: error code, error message, and error details. You can find out more about this error model and how to work with it in the [API Design Guide](https://cloud.google.com/apis/design/errors). - `code` integer: The status code, which should be an enum value of google.rpc.Code. - `message` string: A developer-facing error message, which should be in English. Any user-facing error message should be localized and sent in the google.rpc.Status.details field, or localized by the client. - `details` ProtobufAny[]: A list of messages that carry the error details. There is a common set of message types for APIs to use. - `@type` string: A URL/resource name that uniquely identifies the type of the serialized protocol buffer message. This string must contain at least one "/" character. The last segment of the URL's path must represent the fully qualified name of the type (as in `path/google.protobuf.Duration`). The name should be in a canonical form (e.g., leading "." is not accepted). In practice, teams usually precompile into the binary all types that they expect it to use in the context of Any. However, for URLs which use the scheme `http`, `https`, or no scheme, one can optionally set up a type server that maps type URLs to message definitions as follows: * If no scheme is provided, `https` is assumed. * An HTTP GET on the URL must yield a google.protobuf.Type value in binary format, or produce an error. * Applications are allowed to cache lookup results based on the URL, or have them precompiled into a binary to avoid any lookup. Therefore, binary compatibility needs to be preserved on changes to types. (Use versioned type names to manage breaking changes.) Note: this functionality is not currently available in the official protobuf release, and it is not used for type URLs beginning with type.googleapis.com. Schemes other than `http`, `https` (or the empty scheme) might be used with implementation specific semantics. - `response` ProtobufAny: Contains an arbitrary serialized protocol buffer message along with a type URL that identifies the message type. - `@type` string: A URL/resource name that uniquely identifies the type of the serialized protocol buffer message. This string must contain at least one "/" character. The last segment of the URL's path must represent the fully qualified name of the type (as in `path/google.protobuf.Duration`). The name should be in a canonical form (e.g., leading "." is not accepted). In practice, teams usually precompile into the binary all types that they expect it to use in the context of Any. However, for URLs which use the scheme `http`, `https`, or no scheme, one can optionally set up a type server that maps type URLs to message definitions as follows: * If no scheme is provided, `https` is assumed. * An HTTP GET on the URL must yield a google.protobuf.Type value in binary format, or produce an error. * Applications are allowed to cache lookup results based on the URL, or have them precompiled into a binary to avoid any lookup. Therefore, binary compatibility needs to be preserved on changes to types. (Use versioned type names to manage breaking changes.) Note: this functionality is not currently available in the official protobuf release, and it is not used for type URLs beginning with type.googleapis.com. Schemes other than `http`, `https` (or the empty scheme) might be used with implementation specific semantics. ## Other responses - `default`: An unexpected error response. --- [API](https://skmtc.dev/thirdfort/apis/thirdfort-client-api-preview.md) - [All operations](https://skmtc.dev/thirdfort/apis/thirdfort-client-api-preview/llms.txt) - [OpenAPI document](https://skmtc.dev/thirdfort/apis/thirdfort-client-api-preview/revisions/3446b9aefa90?raw)