Status dynamics

The registration analysis API works with three independent status enumerators. Understanding the difference between them is the step that prevents the most integration errors:

Enumerator	Who defines the value	Who returns it	What it represents
analysis_status	You, in your policy	QI Tech	The result of running your decision tree.
risk_level	You, in your policy	QI Tech	The risk level assigned by your decision tree.
client_status	You	—	The customer's situation on your platform.

analysis_status and risk_level come from your own policy

These two fields are not a verdict of ours about the registration. They are defined by you, in the rules engine, through the decision and risk level blocks you place along your decision tree.

On every request, QI Tech runs that tree against the analyzed data and returns the result your policy determined. If you want a scenario to start falling into in_manual_analysis instead of automatically_reproved, or a profile to receive risk_level: high instead of medium, the change belongs in the rules engine — there is nothing to change in the integration.

The rule of thumb

analysis_status is the result of your policy, executed by us. client_status is your business decision, which you record via PUT as the customer journey evolves.

How the decision is produced

1. You design the decision tree in the rules engine, placing the decision (analysis_status) and risk level (risk_level) blocks according to your policy.
2. You send the registration to the API.
3. QI Tech runs the tree against the registration data and the available enrichments.
4. The response carries the analysis_status and risk_level that your tree determined for that case.

This is why two clients sending exactly the same registration can receive different responses: each one has its own policy configured.

---

analysis_status

The result of running your decision tree. The statuses below fall into three groups according to what you should do with each one.

Final decisions

Status	Meaning	Action
automatically_approved	Your decision tree ended in an automatic approval block.	You may approve the registration.
automatically_reproved	Your decision tree ended in an automatic rejection block.	Decline the registration.
manually_approved	Approved by an analyst.	You may approve the registration.
manually_reproved	Rejected by an analyst.	Decline the registration.
approved_by_time	Automatically approved after the analysis deadline expired.	You may approve the registration.
reproved_by_time	Automatically rejected after the analysis deadline expired.	Decline the registration.

Waiting — the result arrives via webhook

Status	Meaning	Action
in_queue	Asynchronous analysis queued.	Wait for the Webhook.
pending	The queries are taking longer than expected.	Wait for the Webhook.
in_manual_analysis	Your tree routed the case to manual analysis.	Wait for the Webhook.
waiting_for_data	Waiting for additional data to process.	Wait for the Webhook.
on_hold	Analysis paused, waiting for the customer's response.	Wait for the Webhook.

Do not treat "waiting" as a rejection

in_queue, pending, in_manual_analysis, waiting_for_data and on_hold are not negative outcomes. Treating them as rejections is the most common integration error in this API — it declines legitimate registrations that would have been approved minutes later.

Challenges and special cases

Status	Meaning	Action
automatically_challenged	Your tree ended in a challenge block.	The registration must go through the challenge flow.
manually_challenged	Challenged by an analyst.	Same as above.
manually_cancelled	Analysis cancelled.	No decision will be issued.
failed	The analysis failed during processing.	Resubmit with a new id or contact support.
not_analysed	Submitted with analyze=false.	No recommendation will be issued; follow your own decision.

---

client_status

The customer's registration situation on your platform. You are responsible for keeping this status up to date via PUT — it feeds the models and improves future analyses.

Status	Meaning
registered	Registered, with no approval decision yet.
approved	Approved on your platform.
reproved	Rejected on your platform.
fraud_blocked	Blocked due to suspected or confirmed fraud.
default_blocked	Blocked due to default.
cancelled	The customer cancelled the use of the service.

Spelling of the enumerator

The correct value is cancelled, with two L's. Older versions of this documentation spelled it canceled — that value is rejected with HTTP 400.

Which values can be sent

The method used determines the accepted values:

Registration type	Values accepted in PUT
Natural Person	approved, reproved, fraud_blocked, default_blocked, cancelled
Legal Person	fraud_blocked, default_blocked, cancelled

Legal Person accepts fewer values

In Legal Person, PUT does not accept approved or reproved — only the three block and cancellation values. Sending approved on a Legal Person registration returns HTTP 400.

Details in Update a registration.

---

risk_level

The risk level assigned to the registration by the risk level block your tree went through. Present in the GET response and in the analysis events.

Value	Meaning
low	Low risk.
medium	Medium risk.
high	High risk.
critical	Critical risk.
undefined	No risk assessment was performed.

---

Typical flow

1. You submit the registration — POST /onboarding/natural_person.
2. The response returns an analysis_status.
   • If it is a final decision, follow what your policy determined.
   • If it is waiting, wait for the webhook.
3. When you make a decision on your platform, send the client_status via PUT.