# QI Tech — Risk Solutions › PIX Limits Documentação da QI Tech em texto corrido, para colar em um LLM. Fonte: https://docs.qitech.com.br 7 página(s). Índice: - HTTP Status (/en/documentation/caas/limits/http_status) - Introduction (/en/documentation/caas/limits/introduction) - New Limit Registration (/en/documentation/caas/limits/limit_registration) - Creating a Recipient List (/en/documentation/caas/limits/recipient_list) - Standards (/en/documentation/caas/limits/standards) - Status Dynamics (/en/documentation/caas/limits/status_dynamics) - Webhook (/en/documentation/caas/limits/webhook) --- # HTTP Status URL: /en/documentation/caas/limits/http_status All QI Tech APIs use the following standardization for HTTP response status codes, in accordance with RFC 7231 : HTTP Status | Meaning | Description ---------- | ------- | --------------------------------- 400 | Bad Request | The request sent contains a formatting error. In most cases, we return an explanation in the response body indicating where the error is. 401 | Unauthorized | There was an authentication issue. Please verify that the API Key is correct and sent in the proper header, according to the Authentication section. 403 | Forbidden | The accessed endpoint is for internal use and is not available for this API Key. 404 | Not Found | The requested data was not found using the provided key. This status is also returned when an invalid endpoint is requested. 405 | Method Not Allowed | The HTTP method used does not apply to the accessed endpoint. 406 | Not Acceptable | The data sent in the request body is invalid. In general, this means the payload is not a valid JSON. 409 | Conflict | The request ID corresponds to an ID that has already been processed. This status is returned in the case of duplicate requests sent to the server. 500 | Internal Server Error | We encountered an issue while processing this request. When this error occurs, our specialists are automatically notified and immediately begin analysis and resolution. 503 | Service Unavailable | You have encountered a planned or unplanned infrastructure outage of our servers. --- # Introduction URL: /en/documentation/caas/limits/introduction Welcome to the QI Tech Pix Limits API! You can use our API to manage your pix limits: - Register new pix limits; - Modify pre-existing pix limits; - Retrieve pre-existing pix limits. Below, you can see the API implementation using cUrl. This provides you with examples that you can adapt to the programming language of your choice. ## Problems? We are not a company that hides behind an API! Contact our support and we will respond as quickly as possible. Feel free to call us if you need a quick response! ### We Love Feedback Even if you have already solved your problem or it is very simple (even a typo or inadequate organization that you already understood), send us an email, so we can make the documentation increasingly practical and the next person won't have to suffer the pains you suffered! ## Environments We have two environments for our clients. The base API URLs are: * Production - `https://api.caas.qitech.app/limits/` * Sandbox - `https://api.sandbox.caas.qitech.app/limits/` In the Sandbox environment, submitted analyses are not charged and are responded to according to pre-established rules. For transaction analysis, the following rule is applied based on the transaction value: Minimum | Maximum | Decision ------- | ------- | -------- 0 | 1000 | Automatically Approved 1001 | 2000 | Referred to manual analysis - Subsequently approved 2001 | 3000 | Referred to manual analysis - Subsequently rejected 3001 | 4000 | Automatically Rejected 4001 | 5000 | Not analyzed 5001 | - | Pending ## HTTPS Only For security reasons, all communication with QI Tech APIs must be done using HTTPS communication. To prevent HTTP calls from being made due to inattention or other reasons, this server only provides port 443 with TLS 1.2 communication. Calls made using other protocols will be automatically denied. ## Authentication > To authenticate a call, use the following code: ```shell # 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 your key obtained from our support. We use an API Key to allow access to our API. It has probably 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` :::info **Attention** You must replace EXAMPLE_API_KEY with the API Key received from support. ::: --- # New Limit Registration URL: /en/documentation/caas/limits/limit_registration To register a new limit, simply send an _Account_ type object to the following endpoint: `POST https://api.caas.qitech.app/limits/account` > Example ```json { "account_id": "5ce7fab5-8165-44a5-9b89-bb2d6d61e4f4", "registration_date": "2019-12-20T15:23:12", "limit": { "pix": { "withdraw": [ { "start_time": "06:00:00-03:00", "amount": 500000 }, { "start_time": "20:00:00-03:00", "amount": 300000 } ], "change": [ { "start_time": "06:00:00-03:00", "amount": 500000 }, { "start_time": "20:00:00-03:00", "amount": 300000 } ], "transaction_natural_person": [ { "start_time": "06:00:00-03:00", "amount": 500000 }, { "start_time": "20:00:00-03:00", "amount": 300000 } ], "transaction_legal_person": [ { "start_time": "06:00:00-03:00", "amount": 500000 }, { "start_time": "20:00:00-03:00", "amount": 300000 } ] } } } ``` All information exchanges for a registration use the following definition for this object. In some cases, to facilitate implementation and reduce data flow between parties, some information may be omitted. name | type | description :----: | :----: | --------- account_id | string | Unique account identifier. **It is essential that this number is unique for each request** registration_date | string (ISO 8601) | Registration date and time. limit | limit | _limit_ type object. ## Limit Object ```json { "pix": { "withdraw": [ { "start_time": "06:00:00-03:00", "amount": 500000 }, { "start_time": "20:00:00-03:00", "amount": 300000 } ], "change": [ { "start_time": "06:00:00-03:00", "amount": 500000 }, { "start_time": "20:00:00-03:00", "amount": 300000 } ], "transaction": [ { "start_time": "06:00:00-03:00", "amount": 500000 }, { "start_time": "20:00:00-03:00", "amount": 300000 } ] } } ``` This object represents the value limits applicable to different types of transactions at different times of the day, taking into account the division between daytime and nighttime periods. The object is organized into three main categories (or limit types): "withdraw" (referring to PIX Withdrawal mode), "change" (referring to PIX Change mode), and "transaction" (referring to transactional PIX mode). Each category can contain a list of up to two dictionaries, each representing - respectively - the daytime and nighttime limit periods, describing the start time and the respective value limits to be applied for the mode. Limit Window Structure: name | type | description :----: | :----: | --------- start_time | string (ISO 8601) | Indicates the moment when the value limits for PIX transactions are applied. Pay attention to the correct configuration of the Limit Window start according to the time zone you intend to use. amount | integer | Maximum limit value allowed for the mode in the period specified by "start_time" in cents of Brazilian reais. Since, according to Central Bank guidelines, daytime PIX limit windows must start at 6AM, only the value "06:00:00-03:00" will currently be accepted for configuring the start_time of these windows. Similarly, since nighttime PIX limit windows must start at 8PM or 10PM, only the values "20:00:00-03:00" and "22:00:00-03:00", respectively, will be accepted for configuring the start_time of these windows. *Usage Example:* Let's assume the user is making a PIX transaction at 12:00:00-03:00. When consulting the object, we locate the "transaction" category (PIX Transaction). In this category, we find two dictionaries: the first starts at "06:00:00-03:00" and the second starts at "20:00:00-03:00". If the PIX transaction is made between these times, the maximum allowed value limit is 5,000.00 (five thousand) Brazilian reais, as specified in the first limit window. However, if the transaction occurs after "20:00:00-03:00" and before the next start time (in this example, at 06:00 the next day), the maximum allowed value limit will be 3,000.00 (three thousand) Brazilian reais, as indicated in the second (nighttime) limit window. # Creating a Limit Modification Proposal To request a limit modification, simply send a Limit type object to the following endpoint: `POST https://api.caas.qitech.app/limits/account/{account_id}/limit_update_request` > Example ```json { "pix": { "withdraw": [ { "start_time": "06:00:00-03:00", "amount": 500000 }, { "start_time": "20:00:00-03:00", "amount": 300000 } ], "change": [ { "start_time": "06:00:00-03:00", "amount": 500000 }, { "start_time": "20:00:00-03:00", "amount": 300000 } ], "transaction_natural_person": [ { "start_time": "06:00:00-03:00", "amount": 500000 }, { "start_time": "20:00:00-03:00", "amount": 300000 } ] } } ``` Which will return the following response: ```json { "limit_update_request_id": "5ce7fab5-8165-44a5-9b89-bb2d6d61e4f4", "analysis_status": "automatically_approved", "client_notification_status": "not_applicable", "limit_update_request_status": "applied", "event_date": "2019-10-01T10:37:25-03:00" } ``` name | type | description :----: | :----: | --------- limit_update_request_id | string | Unique identifier for the Limit Modification Proposal analysis_status | string | Enumerator for the proposal's analysis_status client_notification_status | string | Enumerator for the proposal's client_notification_status limit_update_request_status | string | Enumerator for the proposal's limit_update_request_status event_date | string (ISO 8601) | Date and time of the Limit Modification Proposal creation --- # Creating a Recipient List URL: /en/documentation/caas/limits/recipient_list According to the Central Bank's PIX limits regulation, it is possible to create a recipient list that will use the same differentiated limit. To request the creation of a recipient list for an account, simply send a Limit type object to the following endpoint: `POST https://api.caas.qitech.app/limits/account/{account_id}/recipient_list` ```json { "limit": { "pix": { "transaction": [ { "start_time": "06:00:00-03:00", "amount": 60000 }, { "start_time": "20:00:00-03:00", "amount": 60000 } ] } } } ``` Which will return the following response: ```json { "event_date": "2019-10-01T10:37:25-03:00" } ``` name | type | description :----: | :----: | --------- event_date | string (ISO 8601) | Date and time of the Recipient List creation # Adding a New Recipient to the Recipient List To add a new recipient to a previously created recipient list, simply make the following request: `POST https://api.caas.qitech.app/limits/account/{account_id}/recipient_list/recipient` ```json { "document_number": "123.456.789-10" } ``` Which will return the following response: ```json { "recipient_id": "c7a79970-b558-4425-998a-5cd6747c1c90", "analysis_status": "automatically_approved", "client_notification_status": "awaiting_notification_period", "recipient_status": "created", "event_date": "2019-10-01T10:37:25-03:00" } ``` name | type | description :----: | :----: | --------- recipient_id | string | Unique identifier of the Recipient for this Limit Modification Proposal analysis_status | string | Enumerator of the proposal's analysis_status client_notification_status | string | Enumerator of the proposal's client_notification_status recipient_status | string | Enumerator of the proposal's recipient_status event_date | string (ISO 8601) | Date and time of the Limit Modification Proposal creation For a better understanding of the return statuses, access status dynamics . # Removing a Recipient To remove a specific recipient from an account, simply send a DELETE request to the following address: `DELETE https://api.caas.qitech.app/limits/account/{account_id}/recipient_list/recipient/{recipient_id}` # Editing the Limits of a Recipient List To request the modification of the recipient limits for a given account, simply send the following request: `POST https://api.caas.qitech.app/limits/account/{account_id}/recipient_list/limit_update_request` ```json { "pix": { "transaction": [ { "start_time": "06:00:00-03:00", "amount": 600000 }, { "start_time": "20:00:00-03:00", "amount": 300000 } ] } } ``` Which will return the following response: ```json { "limit_update_request_id": "c7a79970-b558-4425-998a-5cd6747c1c90", "analysis_status": "automatically_approved", "client_notification_status": "awaiting_notification_period", "recipient_status": "created", "event_date": "2019-10-01T10:37:25-03:00" } ``` name | type | description :----: | :----: | --------- recipient_id | string | Unique identifier of the Recipient for this Limit Modification Proposal analysis_status | string | Enumerator of the proposal's analysis_status client_notification_status | string | Enumerator of the proposal's client_notification_status recipient_status | string | Enumerator of the proposal's recipient_status event_date | string (ISO 8601) | Date and time of the Limit Modification Proposal creation --- # Standards URL: /en/documentation/caas/limits/standards To facilitate integration and ensure data integrity, some standards have been defined and are followed throughout the entire API. ## Date and Time with Time Zone > Some examples: ``` 2019-10-15T22:35:12-03:00 2018-05-01T13:32:11+00:00 2019-05-01T00:00:00+00:00 ``` It is represented according to ISO 8601. In this case, the time zone is placed right after the time and must represent the time zone of the location where that data is valid. For example, if a rental is scheduled to start at 09:30 at Brasília airport, the time sent must be represented as 09:30-03:00. If the rental is scheduled to start at 09:30 in Manaus, it must be represented as 09:30-04:00. The validation mask used is the following: `YYYY-MM-ddThh:mm:ss±hh:mm` ## Date and Time without Time Zone > Some examples: ``` 2019-10-15T22:35:12Z 2018-05-01T13:32:11Z 2019-05-01T00:00:00Z ``` It is represented according to ISO 8601. Data that does not depend on a time zone must be sent without it, always in UTC, with the letter `Z` indicating that the data is in UTC. Therefore, the following format will be validated: `YYYY-MM-ddThh:mm:ssZ` ## Date > Some examples: ``` 2019-10-15 2019-01-01 2017-03-20 ``` For fields that accept only a date, such as a birthdate, only the date should be sent, without any time, using the following format: `YYYY-MM-dd` ## Documents Since document numbers can vary greatly and many of them contain non-numeric characters, all document numbers are defined as strings. Another important reason to define them as strings is to prevent leading zeros from being lost. Documents listed on this page have a well-defined mask and will be subject to validation. Other documents, such as RG, due to their lack of standardization, will not be validated. ## CPF > Examples of CPFs valid against the defined mask: ``` 123.456.789-12 321.987.543-23 111.283.333-00 ``` > Examples of CPFs invalid against the defined mask: ``` 8.577.477-8 08.104.627/0001-23 123.456.789-1 23.456.789-01 ``` The CPF is always defined as a string and will be validated against the mask: `###.###.###-##` ## CNPJ > Examples of CNPJs valid against the defined mask: ``` 08.104.627/0001-02 01.079.210/0114-67 32.402.502/0001-35 ``` > Examples of CNPJs invalid against the defined mask: ``` 8.577.477-8 123.456.789-12 321.987.543-23 32.402.502/0001-3 032.402.502/0001-3 ``` The CNPJ is always defined as a string and will be validated against the mask: `##.###.###/####-##` --- # Status Dynamics URL: /en/documentation/caas/limits/status_dynamics ## Analysis Status (analysis_status) The "analysis_status" indicates the status of the Limit Policy decision. The possible values for "analysis_status" are as follows: analysis_status | Description :---------: | --------- automatically_approved | the Limit Policy automatically approved this limit modification request. automatically_reproved | the Limit Policy automatically rejected this limit modification request. in_manual_analysis | the Limit Policy delegated this limit modification request for manual desk analysis. manually_approved | After manual analysis, the analyst decided to approve the limit modification. manually_reproved | After manual analysis, the analyst decided to reject the limit modification. reproved_by_time | The request was rejected because the analysis time expired. pending | The request is pending to be processed. ## Client Notification Status (client_notification_status) The "client_notification_status" is related to the period during which the client must be notified about the progress of the limit modification request. client_notification_status | Description :---------: | --------- awaiting_notification_period | Indicates that the time window for client notification has not yet started. in_notification_period | Indicates that we are in the time window for client notification. notification_period_expired | Indicates that the time window for client notification has already expired. ## Limit Update Request Status (limit_update_request_status) The "limit_update_request_status" is related to the status of the limit modification request. limit_update_request_status | Description :---------: | --------- created | Indicates that the limit change request was created. applied | Indicates that the limit change request was applied. canceled | Indicates that the limit change request was canceled. ## Recipient List Change Status (recipient_list_append_request_status) The "recipient_list_append_request_status" is related to the status of the recipient list modification request. recipient_list_append_request_status | Description :---------: | --------- created | Indicates that the recipient list change request was created. applied | Indicates that the recipient list change request was applied. canceled | Indicates that the recipient list change request was canceled. --- # Webhook URL: /en/documentation/caas/limits/webhook Webhook Updates to monitoring topics will be notified through webhook deliveries. To enable this, it is necessary to configure—through the [support](mailto:suporte.caas@qitech.com.br) team—an endpoint address where we will send update notifications, as well as a *signature_key* that will be used to sign the request. It is important to note that all webhook deliveries will be sent to a single endpoint. :::info **Attention** For security reasons, all Webhook requests will only be made to endpoints served over HTTPS. ::: ## Webhook Signature ## Retries The notification is considered successfully delivered when an HTTP 200 status is returned. If delivery fails, up to 7 retry attempts will be made with the following intervals, until a 200 response is received or all attempts are exhausted: * 10 seconds * 40 seconds * 160 seconds * 640 seconds * 2560 seconds * 10240 seconds * 40960 seconds