Skip to main content
For us, the connection between systems is essential to ensure that the performance of our applications delivers the intended results for our partners. The implementation of Callbacks becomes indispensable as it enables a range of significant advantages. Through callback calls, it is possible to promote effective communication among all areas involved in the process. This way, there is no need for incessant API polling; instead, we send information, updates, and notifications accurately through callbacks. This reduces the volume of requests, promoting a more efficient flow regarding the overall system performance. The callback for monitoring the status of proposals should be sent to both the homologation environment and the production environment, ideally using different URLs. This callback is sent via Query Parameter.

​
Accepted Authentication Methods for the Callback

AuthenticationKey
Bearer TokenAuthorizationBearer <token>
API KeyAPI-Key<your_api_key>
Basic AuthenticationAuthorizationBasic <base64_encoded_username:password>
X-API-KeyX-API-Key<your_api_key>
Digest AuthenticationAuthorizationDigest <digest_hash>
JWT (JSON Web Token)AuthorizationBearer <JWT_token>
HMAC (Hash-based Message Authentication Code)AuthorizationHMAC <hash_value>
OAuth TokensAuthorizationBearer <OAuth_token>
AWS SignatureAuthorizationAWS <signature>
Client CertificatesCertificate<client_certificate>

​
Example of Proposal Callback

Here’s an example of a URL and how we parameterize it for reception: xxxxxxxxxx.com.br?proposal=&status=&identifier= Where: Proposal: Unique GUID of the proposal generated in the response at the time of inclusion of the proposal. Status: ID of the status of the proposal in our system. Identifier: If sent, this field represents the operation code sent when including the proposal.

​
ID Table

IDDescriptionObjective
0In DraftProposal is in draft
1Under ReviewProposal has been sent to the review queue
2ApprovedProposal has been approved by the credit analysis department
3RejectedProposal has been rejected by the credit analysis department
4CanceledProposal has been canceled by the credit analysis department
5PendingProposal has been marked as pending by the credit analysis department; requires integrator intervention to return to the review queue
6FinalizedProposal has been finalized
7VerifiedProposal has been verified by the formalization department
8ReleasedProposal has been released by the formalization department for payment
9PaidProposal has been paid by the financial department
10AssignedProposal has been assigned to the fund
11Payment PendingProposal has been marked as pending payment due to inconsistencies in banking data; requires integrator intervention to provide the correct payment data and return to the payment queue
Note: In addition to the data already sent in the Query (Proposal GUID, Status, and Identifier), the callbacks for Paid “9” and Payment Pending “11” have a body with the field “Occurrence Description,” which informs the reason for the payment pending when it is status “11,” and when it is status “9,” it returns with the text “Credit or debit executed.” Below are examples of returns: Status 09:
status image
Status 11:
status image

​
Final Considerations

It is recommended that the endpoint configured to receive callbacks mainly functions as a repository, minimizing processing at the time of reception to avoid delays. Implementing complex processes during the reception of callbacks can result in timeouts and communication failures, compromising the efficiency of the system. Opt for processing the received messages asynchronously to improve the performance and reliability of your callback system.