Registration Data Validation Object

The validation of registration data for an existing client must be performed through the Registration Data Validation Event Type endpoint. In the configuration described here, the data being validated is the face: the API checks whether the submitted face matches the face previously registered for that CPF.

The flow has two steps:

1. Face registration. The holder's face must have been registered beforehand in the Face Recognition API, through Creating a registration (POST). This is the reference registration for the CPF.
2. Validation. At a later point in the journey, generate a new face registration (via SDK or API) and send its registration_key to this Event Type. The API compares this new registration with the face registered in step 1.

Event Type scope

Registration Data Validation only compares the submitted face with the face already registered for the CPF. The reference registration remains unchanged after the validation and is managed exclusively by the Face Registration API.

Status Dynamics - analysis_status

The analysis_status field indicates the decision status of the fraud engine. The request response is always synchronous. When the event is sent to manual review, the response returns in_manual_analysis and the manual handling happens asynchronously: the final decision is sent via Webhook. Your integration must handle both scenarios.

Statuses that can be returned in the request response:

analysis_status	description
automatically_approved	QI Tech's algorithms recommend that this event be approved.
automatically_reproved	QI Tech's algorithms recommend that this event be rejected.
automatically_challenge	QI Tech's algorithms recommend that the user take an action to provide more information for the analysis.
in_manual_analysis	QI Tech's algorithms have flagged this event for manual review. The final decision is sent via Webhook.

Statuses sent via Webhook, after manual review:

analysis_status	description
manually_approved	After manual review, the analyst decided to approve the event.
manually_reproved	After manual review, the analyst decided to reject the event.

The full state machine is described in Status Dynamics.

Registration Data Validation Object Definition

Request Body

{
  "id": "ce219137-b7f6-48a5-9b9b-0f1f15ddbf5b",
  "event_date": "2026-07-31T16:01:56.515Z",
  "document_number": "430.684.374-23",
  "face": {
    "registration_key": "bc138845-a0e6-4cb4-a6f6-e3f567baa0f0"
  }
}

Name	Type	Description
id	string	Event identifier in your system, 1 to 50 characters. It is essential that this number is unique for each request (required)
event_date	datetime	Date and time the event occurred in your application, in ISO 8601 with timezone. Accepts an explicit offset (-03:00) or UTC (Z). Dates without a timezone are not accepted. (required)
document_number	string	Holder's CPF with punctuation, in the format XXX.XXX.XXX-XX. This is the key used to look up the face registration in the database. (required)
face	face	Object containing the face registration to be compared with the face registered for the CPF. (required)
face.registration_key	string	Identifier (UUID) of the new face registration generated in Face Recognition, via SDK or API. This is the face that will be compared with the registration previously stored for the CPF, not the registration_key of that stored registration. (required)

Submit a Registration Data Validation

Request Body

  {
    "id": "ce219137-b7f6-48a5-9b9b-0f1f15ddbf5b",
    ...
  }

Response Body - automatically_approved

  {
    "id": "ce219137-b7f6-48a5-9b9b-0f1f15ddbf5b",
    "analysis_status": "automatically_approved",
    "reason": "rosto_deu_match",
    "reason_description": "Rosto deu match"
  }

Response Body - automatically_reproved

  {
    "id": "ce219137-b7f6-48a5-9b9b-0f1f15ddbf5b",
    "analysis_status": "automatically_reproved",
    "reason": "rosto_nao_deu_match",
    "reason_description": "Rosto não deu match"
  }

To perform the validation, simply send a Registration Data Validation type object to the following endpoint:

POST https://api.caas.qitech.app/account_event/event_type/registration_data_validation/event

The response contains the following fields:

Name	Type	Description
id	string	The same id sent in the request, echoed back for correlation.
analysis_status	enumerator	Analysis decision for the event. This is the field your integration must branch on.
reason	string	Reason that determined the decision. Values are defined in each client's configuration, so they vary by integration and by Event Type.
reason_description	string	Human-readable description of the reason, for display in operational screens and audit trails.

The same request can result in any of the statuses, depending on the integration's configuration and the outcome of the comparison:

analysis_status	meaning	expected action in the journey
automatically_approved	The submitted face matches the face registered for the CPF.	Continue the journey. No further action needed.
automatically_reproved	The submitted face does not match the face registered for the CPF.	Block the step and apply the agreed rejection policy. Resubmission only with a new capture.

Branch on analysis_status

The values of reason are defined in each client's configuration. Do not build logic on the text of reason: use it for display and auditing, and branch on analysis_status.