All URIs are relative to https://localhost
Method | HTTP request | Description |
---|---|---|
ChangeClientCredentials | Post /api/v1/mandatorAdmin/changeClientCredentials | Change client credentials |
CreateIbanRules | Post /api/v1/mandatorAdmin/ibanRules | Create IBAN rules |
CreateKeywordRules | Post /api/v1/mandatorAdmin/keywordRules | Create keyword rules |
DeleteIbanRules | Post /api/v1/mandatorAdmin/ibanRules/delete | Delete IBAN rules |
DeleteKeywordRules | Post /api/v1/mandatorAdmin/keywordRules/delete | Delete keyword rules |
DeleteUsers | Post /api/v1/mandatorAdmin/deleteUsers | Delete users |
GetIbanRuleList | Get /api/v1/mandatorAdmin/ibanRules | Get IBAN rules |
GetKeywordRuleList | Get /api/v1/mandatorAdmin/keywordRules | Get keyword rules |
GetUserList | Get /api/v1/mandatorAdmin/getUserList | Get user list |
ChangeClientCredentials(ctx, body) Change client credentials
Change the client_secret for any of your clients, including the mandator admin client. Must pass the mandator admin client's access_token.
NOTES:
• When you change a client's secret, then all of its existing access tokens will be revoked. User access tokens are not affected.
• finAPI is storing client secrets with a one-way encryption. A lost client secret can NOT be recovered.
Name | Type | Description | Notes |
---|---|---|---|
ctx | context.Context | context for authentication, logging, cancellation, deadlines, tracing, etc. | |
body | ChangeClientCredentialsParams | Parameters for changing client credentials |
(empty response body)
- Content-Type: Not defined
- Accept: Not defined
[Back to top] [Back to API list] [Back to Model list] [Back to README]
IbanRuleList CreateIbanRules(ctx, body) Create IBAN rules
This service can be used to define IBAN rules for finAPI's transaction categorization system. The transaction categorization is run automatically whenever new transactions are imported, as well as when you call the services 'Check categorization' or 'Trigger categorization'.
An IBAN rule maps an IBAN to a certain category. finAPI's categorization system will pick the category as a candidate for any transaction whose counterpart's account matches the IBAN. It is not guaranteed though that this candidate will actually be applied, as there could be other categorization rules that have higher priority or that are an even better match for the transaction.
Note that the rules that you define here will be applied to all of your users. They have higher priority than finAPI's default categorization rules, but lower priority than user-specific rules (User-specific rules are created implicitly whenever a category is manually assigned to a transaction via the PATCH /transactions services). IBAN rules have a higher priority than keyword rules (see the 'Create keyword rules' service).
Name | Type | Description | Notes |
---|---|---|---|
ctx | context.Context | context for authentication, logging, cancellation, deadlines, tracing, etc. | |
body | IbanRulesParams | IBAN rule definitions |
- Content-Type: Not defined
- Accept: Not defined
[Back to top] [Back to API list] [Back to Model list] [Back to README]
KeywordRuleList CreateKeywordRules(ctx, body) Create keyword rules
This service can be used to define keyword rules for finAPI's transaction categorization system. The transaction categorization is run automatically whenever new transactions are imported, as well as when you call the services 'Check categorization' or 'Trigger categorization'.
A keyword rule maps a set of keywords to a certain category. finAPI's categorization system will pick the category as a candidate for any transaction that contains at least one of the defined keywords in its purpose or counterpart information. It is not guaranteed though that this candidate will actually be applied, as there could be other categorization rules that have higher priority or that are an even better match for the transaction. If there are multiple keyword rules that match a transaction, finAPI will pick the one with the highest count of matched keywords.
Note that the rules that you define here will be applied to all of your users. They have higher priority than finAPI's default categorization rules, but lower priority than user-specific rules (User-specific rules are created implicitly whenever a category is manually assigned to a transaction via the PATCH /transactions services). Keyword rules have a lower priority than IBAN rules (see the 'Create IBAN rules' service).
Name | Type | Description | Notes |
---|---|---|---|
ctx | context.Context | context for authentication, logging, cancellation, deadlines, tracing, etc. | |
body | KeywordRulesParams | Keyword rule definitions |
- Content-Type: Not defined
- Accept: Not defined
[Back to top] [Back to API list] [Back to Model list] [Back to README]
IdentifierList DeleteIbanRules(ctx, body) Delete IBAN rules
Delete one or multiple IBAN rules that you have previously created via the 'Create IBAN rules' service.
Name | Type | Description | Notes |
---|---|---|---|
ctx | context.Context | context for authentication, logging, cancellation, deadlines, tracing, etc. | |
body | IdentifiersParams | List of IBAN rules identifiers.The maximum number of identifiers is 100. |
- Content-Type: Not defined
- Accept: Not defined
[Back to top] [Back to API list] [Back to Model list] [Back to README]
IdentifierList DeleteKeywordRules(ctx, body) Delete keyword rules
Delete one or multiple keyword rules that you have previously created via the 'Create keyword rules' service.
Name | Type | Description | Notes |
---|---|---|---|
ctx | context.Context | context for authentication, logging, cancellation, deadlines, tracing, etc. | |
body | IdentifiersParams | List of keyword rule identifiers.The maximum number of identifiers is 100. |
- Content-Type: Not defined
- Accept: Not defined
[Back to top] [Back to API list] [Back to Model list] [Back to README]
UserIdentifiersList DeleteUsers(ctx, body) Delete users
Delete one or several users, which are specified by a given list of identifiers. Must pass the mandator admin client's access_token.
NOTE: finAPI may fail to delete one (or several, or all) of the specified users. A user cannot get deleted when his data is currently locked by an internal process (for instance, update of a bank connection or transactions categorization). The response contains the identifiers of all users that could not get deleted, and all users that could get deleted, separated in two lists. The mandator admin client can retry the request at a later time for the users who could not get deleted.
Name | Type | Description | Notes |
---|---|---|---|
ctx | context.Context | context for authentication, logging, cancellation, deadlines, tracing, etc. | |
body | UserIdentifiersParams | List of user identifiers |
- Content-Type: Not defined
- Accept: Not defined
[Back to top] [Back to API list] [Back to Model list] [Back to README]
PageableIbanRuleList GetIbanRuleList(ctx, optional) Get IBAN rules
Returns all IBAN-based categorization rules that you have defined for your users via the 'Create IBAN rules' service.
Name | Type | Description | Notes |
---|---|---|---|
ctx | context.Context | context for authentication, logging, cancellation, deadlines, tracing, etc. | |
optional | *GetIbanRuleListOpts | optional parameters | nil if no parameters |
Optional parameters are passed through a pointer to a GetIbanRuleListOpts struct
Name | Type | Description | Notes |
---|---|---|---|
page | optional.Int32 | Result page that you want to retrieve | [default to 1] |
perPage | optional.Int32 | Maximum number of records per page. Can be at most 500. NOTE: Due to its validation and visualization, the swagger frontend might show very low performance, or even crashes, when a service responds with a lot of data. It is recommended to use a HTTP client like Postman or DHC instead of our swagger frontend for service calls with large page sizes. | [default to 20] |
- Content-Type: Not defined
- Accept: Not defined
[Back to top] [Back to API list] [Back to Model list] [Back to README]
PageableKeywordRuleList GetKeywordRuleList(ctx, optional) Get keyword rules
Returns all keyword-based categorization rules that you have defined for your users via the 'Create keyword rules' service.
Name | Type | Description | Notes |
---|---|---|---|
ctx | context.Context | context for authentication, logging, cancellation, deadlines, tracing, etc. | |
optional | *GetKeywordRuleListOpts | optional parameters | nil if no parameters |
Optional parameters are passed through a pointer to a GetKeywordRuleListOpts struct
Name | Type | Description | Notes |
---|---|---|---|
page | optional.Int32 | Result page that you want to retrieve | [default to 1] |
perPage | optional.Int32 | Maximum number of records per page. Can be at most 500. NOTE: Due to its validation and visualization, the swagger frontend might show very low performance, or even crashes, when a service responds with a lot of data. It is recommended to use a HTTP client like Postman or DHC instead of our swagger frontend for service calls with large page sizes. | [default to 20] |
- Content-Type: Not defined
- Accept: Not defined
[Back to top] [Back to API list] [Back to Model list] [Back to README]
PageableUserInfoList GetUserList(ctx, optional) Get user list
Get a list of the users of the mandator that is authorized by the access_token. Must pass the mandator admin client's access_token. You can set optional search criteria to get only those users that you are interested in. If you do not specify any search criteria, then this service functions as a 'get all' service.
Note that the original user id is no longer available in finAPI once a user has been deleted. Because of this, the userId of deleted users will be a distorted version of the original userId. For example, if the deleted user's id was originally 'user', then this service will return 'uXXr' as the userId.
Name | Type | Description | Notes |
---|---|---|---|
ctx | context.Context | context for authentication, logging, cancellation, deadlines, tracing, etc. | |
optional | *GetUserListOpts | optional parameters | nil if no parameters |
Optional parameters are passed through a pointer to a GetUserListOpts struct
Name | Type | Description | Notes |
---|---|---|---|
minRegistrationDate | optional.String | Lower bound for a user's registration date, in the format 'YYYY-MM-DD' (e.g. '2016-01-01'). If specified, then only users whose 'registrationDate' is equal to or later than the given date will be regarded. | |
maxRegistrationDate | optional.String | Upper bound for a user's registration date, in the format 'YYYY-MM-DD' (e.g. '2016-01-01'). If specified, then only users whose 'registrationDate' is equal to or earlier than the given date will be regarded. | |
minDeletionDate | optional.String | Lower bound for a user's deletion date, in the format 'YYYY-MM-DD' (e.g. '2016-01-01'). If specified, then only users whose 'deletionDate' is not null, and is equal to or later than the given date will be regarded. | |
maxDeletionDate | optional.String | Upper bound for a user's deletion date, in the format 'YYYY-MM-DD' (e.g. '2016-01-01'). If specified, then only users whose 'deletionDate' is null, or is equal to or earlier than the given date will be regarded. | |
minLastActiveDate | optional.String | Lower bound for a user's last active date, in the format 'YYYY-MM-DD' (e.g. '2016-01-01'). If specified, then only users whose 'lastActiveDate' is not null, and is equal to or later than the given date will be regarded. | |
maxLastActiveDate | optional.String | Upper bound for a user's last active date, in the format 'YYYY-MM-DD' (e.g. '2016-01-01'). If specified, then only users whose 'lastActiveDate' is null, or is equal to or earlier than the given date will be regarded. | |
includeMonthlyStats | optional.Bool | Whether to include the 'monthlyStats' for the returned users. If not specified, then the field defaults to 'false'. | [default to false] |
monthlyStatsStartDate | optional.String | Minimum bound for the monthly stats (=oldest month that should be included). Must be passed in the format 'YYYY-MM'. If not specified, then the monthly stats will go back up to the first month in which the user existed (date of the user's registration). Note that this field is only regarded if 'includeMonthlyStats' = true. | |
monthlyStatsEndDate | optional.String | Maximum bound for the monthly stats (=latest month that should be included). Must be passed in the format 'YYYY-MM'. If not specified, then the monthly stats will go up to either the current month (for active users), or up to the month of deletion (for deleted users). Note that this field is only regarded if 'includeMonthlyStats' = true. | |
minBankConnectionCountInMonthlyStats | optional.Int32 | A value of X means that the service will return only those users which had at least X bank connections imported at any time within the returned monthly stats set. This field is only regarded when 'includeMonthlyStats' is set to 'true'. The default value for this field is 0. | [default to 0] |
isDeleted | optional.Bool | If NOT specified, then the service will regard both active and deleted users in the search. If set to 'true', then ONLY deleted users will be regarded. If set to 'false', then ONLY active users will be regarded. | |
page | optional.Int32 | Result page that you want to retrieve | [default to 1] |
perPage | optional.Int32 | Maximum number of records per page. Can be at most 500. NOTE: Due to its validation and visualization, the swagger frontend might show very low performance, or even crashes, when a service responds with a lot of data. It is recommended to use a HTTP client like Postman or DHC instead of our swagger frontend for service calls with large page sizes. | [default to 20] |
order | optional.Interface of []string | Determines the order of the results. You can order the results by 'userId'. The default order for this service is 'userId,asc'. The general format is: 'property[,asc | desc]', with 'asc' being the default value. |
- Content-Type: Not defined
- Accept: Not defined
[Back to top] [Back to API list] [Back to Model list] [Back to README]