Quickstart
With this quickstart guide, we have tried to make it as easy as possible to get up and running with Flanks.
If you have any questions along the way, please refer to: [email protected]
To help you get oriented with Flanks API and what it can help you to do, let’s start by defining some basics:
access_token | An OAuth Token allows you to identify as your company and application with Flanks API in a secure way. |
credentials_token | Allows you to identify, the set of username, password and entity. |
Though
access_token and credentials_token are the same across all environments, use our Sandbox and Development environments to build out and test your integration with simulated and live users, respectively. You will move over to our Production environment once you are ready to go live!
- Sandbox: Stateful sandbox environment; use test credentials and build out and test your integration.
- Development: Test your integration with live credentials; you will need to request access before you can move to our Development environment.
- Production: Production API environment.
Most API requests interact with a
credentials_token associated with a credentials for online website financial institution. A single end-user of your application might have different credentials for different financial institutions.Credit and depository accounts may also have transactions associated with them.
That
credentials_token uniquely identifies the credentials (composed by username, password and entity name) in Flanks System. You can use the credentials_token along with your access_token to get the products and transactions extracted from the financial entity website.Read on for more information about each of our products and how you create and access data for a given credentials_token.
The simplest and the secure way to connect with our products is using Flanks Link. You can:
- Redirect your user to Flanks Link using a button in your platform/application
- Embed Flanks link in your platform/application
Our Link is costumizable and by default it looks like this:
Flanks Link - Bank selection
Flanks Link - Credentials form
Once the user has connected through Flanks Link, everything necessary to operate with the data that the user has given his consent will be sent.
Once you create a
credentials_token, you can then access data—such as transaction data, account information —using our API endpoints. You access data using the credentials_token, which is specific to your API keys and cannot be shared or used by any other API keys. By default, a credentials_token never expires unless you delete it. To integrate an existing architecture with the Flanks API, you might try using a table to storecredentials_tokenthat map credentials that your users has connected to Flanks.
| |
Transactions | Clean transaction data going back as far as 24 months. Transaction data may include context such as merchant, and category information. |
Assets | Streamline borrower experiences by verifying assets, including account balances, transaction histories and account holder identity information. |
As we noted above, a
credentials_token represents accounts at a given financial institution, bank, or credit union. Flanks supports many of different institutions, and we are constantly working to add more. Though information integration does change, our API stays up-to-date with Flanks's latest institution coverage at all times and makes it easy for users to find their intended institution.In order to interact with Flanks API, you need an OAuth Token.
Obtaining an OAuth Token is simple. First, if you don't have it, you have to create an account at our Platform; from there, you can create an App. The steps are detailed here:
Then, you can use your app's
CLIENT_ID and CLIENT_SECRET credentials to retrieve an OAuth Token (access_token) using our Authentication endpoint:That's it! You can now use your access_token in your API calls.
In each request you are allowed to add a query field, in request body, in order to filter the retrieved data.
{
"query": {
"fieldName1": [
"fieldQuery1",
"fieldQuery2",
// ...
"fieldQueryN"
],
// ...
"fieldNameN": [
// ...
]
}
}
For each field in the query, we introduce a list with a certain number of queries or filters. These filters act as a disjunction, as the query will return any object that matches at least one of these filters for each field.
Now, we specify the syntax for each field filter depending on the filter type.
A query on a string typed field should be a valid regular expression. In particular, any string is a valid regular expression that matches to that exact string, but more complex queries can be made using them.
For example:
{
"query": {
"description": [
"^TRANSFERENCIA.*", // matches all objects whose field "description" starts with "TRANSFERENCIA",
"TRIVAGO" // matches all objects that contain the word TRIVAGO in the field "description"
"^INGRESO CAJERO$" // matches all objects whose field "description" is exactly "INGRESO CAJERO"
]
}
}
By ordered field, we mean any type of value where we can define a relationship of order, i.e. saying A is greater/lesser than B. In particular, these are meant to be applied to numbers and dates.
These filters, as of right now, accept the relationships "greater or equal than", and "lesser or equal than", and each query should be written as a dictionary whose keys can be "gte" or "lte" for each of the mentioned relationships respectively, and whose values should be of the same type of the queried field.
For example:
{
"query": {
"amount": [
{
"lte": 20,
"gte": 10
}, // matches all objects whose field "amount" is in the interval [10, 20]
{
"gte", 100
}, // matches all objects whose field "amount" is in the interval [100, inf]
{
"lte": -5
} // matches all objects whose field "amount" is in the interval [-inf, -5]
]
}
}
These are the fields that can be used in order to filter account transactions output.
- _id
- description
- amount
- operationDate
- valueDate
- category
- currency
- shop
- account_id
- card_id
- investment_id
- liability_id
- portfolio_id
Last modified 26d ago