Introduction
Welcome to the QI Tech Banking API! This API grants access to fraud prevention functionality for bank operations and digital accounts, such as analyzing transfers, bill payments, and bankslip (boleto) payments.
Below, you can see the API implementation using cUrl. This provides examples that you can adapt to your preferred programming language.
Problems?
We are not a company that hides behind an API! Contact our support team, and we will respond as quickly as possible. Feel free to call us if you need a quick answer!
We Love Feedback
Even if you have already solved your problem or if it is very simple (even a typo or improper organization you noticed), send us an email. This helps us make the documentation increasingly practical so the next person won't have to go through the same struggles you did!
Environments
We have two environments for our clients. The base URLs for the APIs are:
- Production -
https://api.caas.qitech.app/ - Sandbox -
https://api.sandbox.caas.qitech.app/
Real data of individuals (natural persons) and/or legal entities must not be used in the QI Tech Sandbox environments.
Sandbox Environment Analysis
In the Sandbox environment, analyses are not charged and are responded to according to simplified rules. In the case of wire_transfers, bankslips, bill_payments, and pix, the response provided will be based on the operation value (amount) sent in the request:
| minimum | maximum | decision |
|---|---|---|
| 16000 | - | Automatically Contested* |
| 10000 | 15999 | Automatically Approved |
| 6000 | 9999 | Forwarded for Manual Analysis |
| 0 | 5999 | Automatically Reproved |
* Automatically Contested is available only for the pix service.
In the case of withdrawal and deposit, the response provided will be based on the operation value (amount) sent in the request:
| minimum | maximum | decision |
|---|---|---|
| 10000 | - | Automatically Approved |
| 0 | 9999 | Automatically Reproved |
In the case of DICT operations, the response provided will be based on the DICT link key (dict_key) sent in the request:
| Key in Dict | decision |
|---|---|
| "Approve_dict_key" | Automatically Approved |
| Any other string | Forwarded for Manual Analysis |
| "Reprove_dict_key" | Automatically Reproved |
HTTPS Only
For security reasons, all communication with QI Tech APIs must be performed using HTTPS communication. To prevent HTTP calls from being made due to inattention or other reasons, this server only makes port 443 available with TLS 1.2 communication. Calls made using other protocols will be automatically denied.
Workflows - Transfers
The transfer analysis flow is initiated in two situations:
- A transfer is being made by the PSP user
- A transfer is being received by the PSP user
In both cases, a call to the wire_transfer endpoint must be made, and the possible resulting statuses are:
| enumerator | description |
|---|---|
| automatically_approved | Automatically Approved |
| automatically_reproved | Automatically Reproved |
| in_manual_analysis | Forwarded for Manual Analysis |
| pending | The bank transfer object is being processed. |
If the transfer is forwarded for manual analysis, an analyst must approve or reject the transfer. At this moment, a Webhook can be generated to notify the PSP of the status change, or the PSP may track the transfer via Polling. In both cases, the following statuses may be returned:
| enumerator | description |
|---|---|
| manually_approved | Manually Approved |
| manually_reproved | Manually Reproved |
Workflows - Bankslips
The Bankslip analysis flow is initiated in two situations:
- A bankslip payment is being made by the PSP user
- A bankslip payment is being received by the PSP user
In both cases, a call to the bankslip endpoint must be made, and the possible resulting statuses are:
| enumerator | description |
|---|---|
| automatically_approved | Automatically Approved |
| automatically_reproved | Automatically Reproved |
| in_manual_analysis | Forwarded for Manual Analysis |
| pending | The bankslip object is being processed. |
If the bankslip payment is forwarded for manual analysis, an analyst must approve or reject the payment. At this moment, a Webhook may be generated to notify the PSP of the status change, or the PSP may track the payment via Polling. In both cases, the following statuses may be returned:
| enumerator | description |
|---|---|
| manually_approved | Manually Approved |
| manually_reproved | Manually Reproved |
Workflows - Bill Payments
The Bill Payment analysis flow is initiated when:
- A bill payment is being made by the PSP user
In this case, a call to the bill_payment endpoint must be made, and the possible resulting statuses are:
| enumerator | description |
|---|---|
| automatically_approved | Automatically Approved |
| automatically_reproved | Automatically Reproved |
| in_manual_analysis | Forwarded for Manual Analysis |
| pending | The bill payment object is being processed. |
If the bill payment is forwarded for manual analysis, an analyst must approve or reject the payment. At this moment, a Webhook may be generated to notify the PSP of the status change, or the PSP may track the payment via Polling. In both cases, the following statuses may be returned:
| enumerator | description |
|---|---|
| manually_approved | Manually Approved |
| manually_reproved | Manually Reproved |
Workflows - Withdrawals
The Withdrawal analysis flow is initiated in the following situation:
- A withdrawal is being made by the PSP user
In this case, a call to the withdrawal endpoint must be made, and the possible resulting statuses are:
| enumerator | description |
|---|---|
| automatically_approved | Automatically Approved |
| automatically_reproved | Automatically Reproved |
If the withdrawal is forwarded for manual analysis, an analyst must approve or reject the withdrawal. At this moment, a Webhook may be generated to notify the PSP of the status change, or the PSP may track the payment via Polling. In both cases, the following statuses may be returned:
| enumerator | description |
|---|---|
| manually_approved | Manually Approved |
| manually_reproved | Manually Reproved |
Workflows - PIX Transaction
The PIX payment flow is initiated in two situations:
- A payment being made by the PSP user integrated with QI Tech
- A payment being received from another PSP
In both cases, a call to the payment endpoint must be made, and the possible resulting statuses are:
| enumerator | description |
|---|---|
| automatically_approved | Automatically Approved |
| automatically_reproved | Automatically Reproved |
| in_manual_analysis | Forwarded for Manual Analysis |
If the payment is forwarded for manual analysis, an analyst must approve or reject the payment. At this moment, a Webhook may be generated to notify the PSP of the status change, or the PSP may track the payment via Polling. In both cases, the following statuses may be returned:
| enumerator | description |
|---|---|
| manually_approved | Manually Approved |
| manually_reproved | Manually Reproved |
Workflows - DICT Changes
The DICT alteration flow is initiated in two situations:
- The PSP user integrated with QI Tech requests a registration/change/portability/claim to the PSP integrated with QI Tech
- A portability/claim is received by the PSP integrated with QI Tech
For registrations initiated by the PSP user, the key validation flow must be executed before the alteration in DICT, using QI Tech's validation APIs. If the validation is performed by the PSP itself, this information can also be sent in the request to QI Tech.
To start the process in these two moments, the PSP integrated with QI Tech must make a call to the appropriate endpoint, which will respond with one of the following statuses:
| enumerator | description |
|---|---|
| automatically_approved | Automatically Approved |
| automatically_reproved | Automatically Reproved |
| in_manual_analysis | Forwarded for Manual Analysis |
If the alteration is forwarded for manual analysis, an analyst must approve or reject the alteration. At this moment, a Webhook may be generated to notify the PSP of the status change, or the PSP may track the alteration via Polling. In both cases, the following statuses may be returned:
| enumerator | description |
|---|---|
| manually_approved | Manually Approved |
| manually_reproved | Manually Reproved |
Authentication
To authenticate a call, use the following code:
# In the shell, you only need to add the appropriate header to each request
curl "api_endpoint_here"
-H "Authorization: EXAMPLE_API_KEY"
Replace the API key 'EXAMPLE_API_KEY' with the key acquired from our support.
We use an API Key to allow access to our API. It has likely already been sent to you by email. If you have not yet received your key, send an email to suporte.caas@qitech.com.br.
Our API expects to receive the API Key in all requests to our server in a header like the one below:
Authorization: EXAMPLE_API_KEY
You must replace EXAMPLE_API_KEY with the API Key received from support.