A standard banking integration flow with Belvo looks likes this:
- Register a link using the Connect Widget
Your end user connects to their account using our Connect Widget. After they've successfully connected, you'll receive a Link ID that you'll need to use in order to make further requests about the end user.
- Wait for historical webhook event
As soon as your user connects their account, Belvo retrieves historical data about the user and sends a webhook once the information is loaded. Once you receive the webhook, you can make a GET request to the appropriate endpoint to retrieve the information.
- Receive update webhook
Depending on the recurrent link update frequency you set, Belvo retrieves updated information and sends a webhook indicating new information is available for the link. When you receive the webhook, just send a GET request to the appropriate endpoint.
As soon as you register a link, you will not have to do it again. You can use the
link.detail to access it in the future.
Same for the accounts, transactions and owners. As soon as you have pulled the data from the institution, you can keep accessing it directly from Belvo through the
Finally, you can delete any data from Belvo by calling the
destroy endpoint on links, accounts, transactions and owners. Note that deleting a link will also delete all the related accounts, transactions and owners, and deleting an account will also delete all the related transactions
All our endpoints are associated with a HTTP Method with the following standard
Access data from Belvo.
Connect to the institution to register or retrieve data. Retrieved data will be stored by Belvo so that you can access it in the future.
Resume a previous connection request (POST) to the institution to add a 2FA token.
Delete data from Belvo.
Errors are annoying - we know. That's why we have dedicated articles for each error in our DevPortal to help you solve them. Have a look at the pages below, or just search for the error code you are encountering to go straight to the causes as well as solutions.
Here is our recommendation in terms of retry on errors:
Implement an automated exponential backoff of up to five retries. We recommend that you use a base interval of three seconds with a factor of two. For example, the first retry should be after three seconds, the second retry is after 6 seconds (2*3), the third retry is after 12 seconds (2*6), the fourth retry is after 24 seconds (2*12), and the fifth retry is after 48 seconds (2*24).
You should not retry making requests if you get 40x response as this is a client error.
The only exception is the “Too Many Sessions” error, as it means that your end-user is accessing the account from another browser at the same time. In this case, please implement the same retry policy as with 50x errors.
Updated 5 days ago