NAV
code

Introduction

Overview

Kontomatik is a read-only API to banks. Kontomatik is able to import personal data, account balances and full statements from any supported bank into your system. To do that, Kontomatik API will need end-user bank credentials (most often a bank login and password). To ask the end user for his bank credentials, we offer a widget that you can embed on your website, as an iframe.

Kontomatik Demo

Kontomatik Demo is example Kontomatik deployment. See how things can work for your end users. Kontomatik Demo allows for real data import to prove our technology worldwide.

While using the demo, don’t forget that Kontomatik is just an API, plus a small widget. You need to build your web app or mobile app on top of it. The frontend look-and-feel is entirely up to you.

Ask for demo access.

Permissionless innovation

Under the hood, Kontomatik uses screen-scraping to mimic a human using his web browser. By using the very same protocol as a web browser, Kontomatik can potentially support any online bank worldwide.

Glossary

Word Description
Command Provides interaction with a remote online transaction system.
Session Context for all commands that interact with a remote online transaction system.
Sign-in widget Embeddable iframe providing a convenient and secure way of authenticating into a remote transaction system. The end user can select the target from a long (and constantly-growing) list of banks. Once the end user has successfully logged in, you can use Kontomatik API server-side to import data.
Target Online transaction system (internet banking platform). In the future, the API will likely support non-banking institutions, so please prefer the more general term ‘target’, instead of 'bank’, in your implementation.
User The end user who owns bank credentials.

API Conventions

Get API access

Authentication

Kontomatik API is protected by two-factor authentication:

Test environment

Use the test environment for testing and development.

The test environment is fully-featured and unrestricted, including real data import.

We kindly ask you to not use it for your production deployments.

The test API endpoint is: https://test.api.kontomatik.com/

Request test API access at kontomatik.com.

Production environment

The production API endpoint is: https://api.kontomatik.com/

To request your production API access, please contact your sales representative.

Kontomatik is also offered in the on-premises model. Contact our Sales team to get the best offer for your individual use case.

Switching from the test to the production environment

Migrating to the production environment is fairly easy. To avoid getting a “We don’t know who you are…” error, please pay attention to the following:

That’s it! You are good to go.

SignIn Widget

Overview

Kontomatik SignIn Widget takes end-to-end care of the bank selection and login process, at the end providing you with an authenticated session so you can focus on reading the data.

Kontomatik SignIn Widget:

Kontomatik SignIn Widget is an HTML5 iframe element that you embed on your website by calling our JavaScript.

Upon successful sign-in, you will be provided with the sessionId and sessionIdSignature parameters. You will need them to execute Kontomatik API commands.

Embedding the widget

<!-- index.html / head -->
<script src="https://signin.kontomatik.com/assets/signin-widget.js">
</script>

<!-- index.html / body -->
<div id="kontomatik" />

// index.js
embedKontomatik({
  client: 'YOUR_CLIENT_ID',  // replace it with your assigned client id
  divId: 'kontomatik',       // must match the div element id
  onSuccess: function(target, sessionId, sessionIdSignature) {
    // End-user successfully signed in to the bank
    // Pass target, sessionId and sessionIdSignature to your backend
    alert('It works!');
  }
});

To embed the widget on your web page:

See the minimal example in the code section.

The client param identifies you and selects the API endpoint. See test and production to learn how to claim your API access.

Customizing the widget

<!DOCTYPE html>
<html>
<head>
  <script src="https://signin.kontomatik.com/assets/signin-widget.js">
  </script>
</head>
<body>

  <div id="kontomatik"></div>

  <script>
    embedKontomatik({
      client: 'YOUR_CLIENT_ID',  // replace it with your assigned client id
      divId: 'kontomatik',
      onSuccess: function(target, sessionId, sessionIdSignature, options) {
        // End user successfully signed in to the bank
        // Pass target, sessionId and sessionIdSignature to your backend
      },
      country: 'es',
      locale: 'en',
      ownerExternalId: 'SERVER_SIDE_RENDERED_VALUE_HERE',
      showFavicons: true
    });
  </script>
</body>
</html>

See the full example on the right pane.

The embedKontomatik() function can take the following parameters.

Parameter Default Description
client obligatory The client id you received from us. You will likely have two of them - one for the test and one for production API. See embedding the widget for details.
divId obligatory Where to render the widget. Make sure this div element already exists before calling the embedKontomatik() function.
onSuccess obligatory Callback function for end-user successful login into the bank. Please see onSuccess callback description for more details.
country null Pre-selects the country. If omitted, the country drop down list will be shown. Accepted values: br cz es uk mx pl ru it.
locale en Determines end-user interface language. Accepted values: br cz en es mx pl ru.
ownerExternalId null Your own arbitrary identifier of the end user. For a lender, this might be your loan application id. If you are a bank, a credit application id might be appropriate. If you are a PFM vendor, this could be your end-user database id. Passing this param is highly recommended. It allows you to group all imported data and fetch them together, even if they span across multiple Kontomatik sessions.
showFavicons false Set to true to show banks’ favicons in a drop down list. Makes it easier for the end user to find a bank. Also it looks more appealing and professional. This is off by default because using bank logotypes can be a grey area in some jurisdictions.
showBetaQualityLabels true Option to control whether beta quality banks display the warning label - (beta)
showTargetMissingOption true By default, “My bank is not listed…” option is displayed on the bank selection list. Set the value to false if you do not want this option to show up on the list.
showTargetMissingForm true Option to control whether the user who clicked on “My bank is not listed…” option is then redirected to a form prompting him to enter the name and url address of the unsupported bank. Passing false enables you to handle this scenario however you prefer.
showDefaultTarget true The widget displays a bank with a large market share as the default value of the bank selection list. If instead of a default target you prefer to display the message Select from list, set showDefaultTarget to false.
onError null Callback function for end-user failed login attempt into the bank (for any reason). Please note that you do not have to implement this. The widget handles error paths gracefully. This only serves informational purposes and should not affect your UI flow. Please see onError callback description for more details.
styles null Optional object defining the look and feel of the widget. For more information please refer to styling the widget section.
onUnsupportedTarget null Callback function fired when the user clicks “My bank is not listed…” option on the bank selection list. Please see onUnsupportedTarget callback description for more details.

onSuccess callback

When the user successfully signs into the banking system the onSuccess callback is called. It will be passed the following parameters:

Parameter Description
target an identifier of the bank the end user has signed into
sessionId an identifier of the Kontomatik session
sessionIdSignature signature created for the sessionId to detect any attempt to tamper with its value
options an object containing extra properties, a more detailed explanation follows below

At the very least you should pass the sessionId and sessionIdSignature parameters to your backend application, which will use them later on to call Kontomatik API.

For approved clients only, the widget will prompt for a full password even though only selected characters from the credential are needed to log into the bank. This feature is useful for PFM tools, that store the end user’s credential in browser’s local storage. For a more detailed description of possible use case please see our FAQ

The options object contains the following attributes:

Attribute Available Description
endUserFingerprint always the attribute value,that can be used to identify the end user to decide whether to continue or abandon Kontomatik session
credentials restricted an array of objects with three attributes: kind, value and unmasked. The kind attribute is an identifier for the credential type, the end user provided value for. The value attribute contains the credential as it was sent by the widget to the online system. The unmasked attribute contains the full credential as it was entered by the end user.

Note: By default, the options object will never contain a credentials array. You must specifically ask for this feature to be enabled.

onError callback

The onError callback is called when the user fails to sign into the bank (i.e. the user provided invalid credentials, the bank transactions system is offline). It will be passed the following parameters:

Parameter Description
exception indicates what went wrong during the attempt to sign in. For more details please refer to error handling.
options an object containing extra properties. It contains two attributes - target, an identifier of the bank the end user has attempted to sign into and sessionId, an identifier of the session that has resulted in an error.

onUnsupportedTarget callback

In case when the user’s bank is not listed, the user can select “My bank is not listed…” option on the dropdown list. The user is then redirected to a form, where he or she is prompted to enter the name and the url address of the missing bank. Regardless whether the user enters any text, the onUnsupportedTarget callback is fired. It will be passed an object with the following attributes:

Attribute Description
target the name of the bank the user has entered
country location of the requested bank
address the url address of the bank’s login page

CSS styling the widget

embedKontomatik({
  /*
  ... (see Embedding the widget for the full reference) ...
  */
  styles: {
    bodyBgColor: '#20252b',
    textColor: '#ebebeb',
    borderRadius: '10px',
    btnBgColor: '#4e5d6c',
    btnBorderColor: 'transparent',
    btnTextColor: '#fff',
    btnPrimaryBgColor: '#e76d3b',
    btnPrimaryBorderColor: 'transparent',
    btnPrimaryTextColor: '#fff',
    inputBgColor: '#4e5d6c',
    inputBorderColor: 'transparent',
    inputBorderFocusColor: '#2c97de',
    inputTextColor: '#fff',
    inputDisabledTextColor: '#b4bcc2',
    alertErrorBgColor: '#d9534f',
    alertErrorBorderColor: 'transparent',
    alertErrorTextColor: '#fff',
    menuHighlightBgColor: '#2c3e50'
  }
});

Scope and approach

Widget offers easy customization of colors but no arbitrary CSS overrides.

Why no CSS overrides? We improve the widget every month in a CSS-breaking way to further optimize conversion rate, security and usability.

Allowing for arbitrary CSS overrides would effectively block us from ongoing widget development (or we would break our customers layouts).

This limitation brings mutual benefits - you automatically get all important improvements, for free.

We believe you can get very close to your ideal visual effect just by smartly customizing the colors.

How to customize the colors?

Customization is achieved by passing the styles: { /* ... */ } option to embedKontomatik() function.

For a complete list of styles object properties see the following table.

Key Description
alertErrorBgColor
alertErrorBorderColor
alertErrorTextColor
 respectively controls the background, border and text color of an error message alert box
bodyBgColor the background color of the widget
borderRadius controls the corner roundness of all input components (buttons, inputs, alert box). The default value is 4px
btnBgColor
btnBorderColor
btnTextColor
 respectively controls the background, border and text color of the “Change bank” button
btnPrimaryBgColor
btnPrimaryBorderColor
btnPrimaryTextColor		 respectively controls the background, border and text color of the “Next” and “Try again” buttons
inputBgColor
inputBorderColor
inputTextColor
inputDisabledTextColor
inputBorderFocusColor		 the first three keys control the background, border and text color of all inputs and dropdown lists. The inputDisabledTextColor key controls the text color of disabled element. The last key - inputBorderFocusColor - controls the border color of an input that has focus
menuHighlightBgColor controls the background color of a menu item the mouse pointer is over
textColor text color

The color values use a subset of standard CSS color definitions, you can use both the hexadecimal (#123456) as well as the standard RGB (rgb(12, 34, 56)) notations.

Additionally, you can also use transparent and inherit keywords. However the RGBA, HSL and HSLA notations are not supported. You cannot use predefined HTML and CSS color names.

The properties which take length values accept standard CSS length units like px, em and so on.

Best practices

For the end user the task of submitting bank credentials on your non-bank website can be a surprising and tricky task.

We must aim to make this process as pleasant and smooth as possible.

To maximize the conversion rate we highly recommend adhering to the following guidelines:

Provide extensive description

Make the widget a separate step in the application process

We strongly recommend to make the widget an individual and completely separate step in the loan application process:

Consider making Kontomatik the primary scenario/path in your loan application process

Some of our clients use Kontomatik as the only or the primary scenario in their loan application processes.

Of course, details vary between markets and it is not always realistic to expect all users to go through Kontomatik.

Give users something to do while background import takes place

Design the loan application form so that the Kontomatik Sign-In widget is one of the intermediary steps. The import process takes a short while to complete, so the end user might just as well continue filling out the rest of the application form.

Use gzip encoding in your HTTP requests to download data faster

Request

curl --get \
  --header "Accept-Encoding: gzip" \
  https://test.api.kontomatik.com/isItWorking

In your HTTP client library add the Accept-Encoding header for all HTTP requests:

Accept-Encoding: gzip

Basic API

Tutorial

We recommend to get API access for this section, if you haven’t done so already.

The first step is to embed the SignIn Widget on your website. Kontomatik SignIn widget takes care of asking the end user for his bank credentials and logging into the bank on his behalf.

The following steps depict a common scenario to download all essential data.

Default import command

Request

curl -X POST \
  --data "apiKey=YOUR_LONG_API_KEY_HERE" \
  --data "sessionId=999999" \
  --data "sessionIdSignature=ffff....ffff" \
  --data "since=YYYY-MM-DD" \
  https://test.api.kontomatik.com/v1/command/default-import.xml

Response

<?xml version="1.0" encoding="utf-8"?>
<reply status="202 Accepted">
  <command id="000000" state="in_progress" name="DefaultImportCommand">
    <progress><value>0</value></progress>
  </command>
</reply>

Final result of polling for this command status

<?xml version="1.0" encoding="utf-8"?>
<reply status="200 OK">
  <command id="653643" state="successful" name="DefaultImportCommand">
    <progress><value>13</value></progress>
    <result>
      <owners>
        <owner>
          <name>Jan Kowalski</name>
          <address>Kwiatowa 8/97 Warszawa  PL</address>
          <polishPesel>84011806651</polishPesel>
          <phone>+48612***078</phone>
          <email>jankowalski@xgmail.com</email>
          <citizenship>PL</citizenship>
          <personalDocumentType>Identity document</personalDocumentType>
          <personalDocumentNumber>AAB123456</personalDocumentNumber>
          <birthDate>1984-01-18</birthDate>
          <kind>OWNER</kind>
        </owner>
        <!-- ... more owners ... -->
      </owners>
      <accounts>
        <account>
          <name>eKONTO</name>
          <iban>PL32114020040000320250132522</iban>
          <currencyBalance>1467.39</currencyBalance>
          <currencyFundsAvailable>1407.39</currencyFundsAvailable>
          <currencyName>PLN</currencyName>
          <owner>Jan Kowalski, Adam Nowak</owner>
          <activeSinceAtLeast>2000-02-28</activeSinceAtLeast>
          <moneyTransactions>
            <moneyTransaction>
              <transactionOn>2012-06-28</transactionOn>
              <bookedOn>2012-06-30</bookedOn>
              <currencyAmount>20.00</currencyAmount>
              <title>Return for beer in a pub</title>
              <party>Jan Kowalski</party>
              <partyIban>PL68249000050000400075212326</partyIban>
              <kind>EXTERNAL INCOMING TRANSFER</kind>
              <labels>
                <label><!-- label type --></label>
                <!-- ... more labels ... -->
              </labels>
            </moneyTransaction>
            <!-- ... more transactions ... -->
          </moneyTransactions>
        </account>
        <!-- ... more accounts ... -->
      </accounts>
    </result>
  </command>
</reply>

Initiates the default data import flow. Use it to get started quickly. This command will import all essential data with one API call.

This will get you:

The command is asynchronous. It returns command id. Use this call to poll for command status and to fetch results once the command is done.

Important. After the command successfully completes, the user is automatically signed out of the bank’s transaction system.

HTTP Request

POST /v1/command/default-import.xml

Parameters

Parameter Default Description
apiKey obligatory API key.
sessionId obligatory Session identifier.
sessionIdSignature obligatory Signature preventing session id enumeration by attacker.
since obligatory Start date in YYYY-MM-DD format. Only transactions that occurred on or after the since date will be imported.

Data returned

Command execution can take anywhere from several seconds to several minutes, with 12s being our global median. You will learn when it’s done by polling for the command status.

Once the command status turns to successful the <result> element will be present containing all imported data.

See on the right pane how the data structure looks like. You will get <owners>, <accounts>, and <moneyTransactions> all together.

For a detailed description of all XML elements see the documentation of the relevant commands in the advanced API.

Default import flow VS custom import flow

The default-import command is a high-level API on top of primitive commands, such as import-owners, import-accounts, import-account-transactions.

The primitive commands allow you to independently import owners and/or accounts and/or transactions on the selected accounts. You can build your custom-tailored import flow. In fact, the default-import is simply a macro-command implemented on top of other commands.

Command status

Request

curl --get \
  --data "apiKey=YOUR_LONG_API_KEY_HERE" \
  --data "sessionId=999999" \
  --data "sessionIdSignature=ffff....ffff" \
  https://test.api.kontomatik.com/v1/command/000000.xml

Response for command in setup state

<?xml version="1.0" encoding="utf-8"?>
<reply status="200 OK">
  <command id="000000" state="setup" name="...">
    <progress><value>0</value></progress>
  </command>
</reply>

Response for command in in_progress state

<?xml version="1.0" encoding="utf-8"?>
<reply status="200 OK">
  <command id="000000" state="in_progress" name="...">
    <progress><value>8</value></progress>
  </command>
</reply>

Response for command in successful state:

<?xml version="1.0" encoding="utf-8"?>
<reply status="200 OK">
  <command id="000000" state="successful" name="...">
    <progress><value>123</value></progress>
    <result>
      <!-- imported data, command specific -->
    </result>
  </command>
</reply>

Response for command in cancelled state

<?xml version="1.0" encoding="utf-8"?>
<reply status="200 OK">
  <command id="000000" state="cancelled" name="...">
    <progress><value>123</value></progress>
  </command>
</reply>

Response for command in error state:

<?xml version="1.0" encoding="utf-8"?>
<reply status="200 OK">
  <command id="000000" state="error" name="...">
    <progress><value>20</value></progress>
    <exception name="SessionExpired">
      <message>Exception message</message>
    </exception>
  </command>
</reply>

Response for command in fatal state:

<?xml version="1.0" encoding="utf-8"?>
<reply status="200 OK">
  <command id="000000" state="fatal">
    <progress><value>25</value></progress>
    <exception name="ExampleException">
      <message>Exception message</message>
      <stacktrace>
        <!-- java stacktrace -->
      </stacktrace>
    </exception>
  </command>
</reply>

Returns information about the status and progress of the command. Once the command has successfully completed, the request will also return the imported data.

Most of the commands are asynchronous and upon initiating them, the command identifier is immediately returned to the client. The client should poll the status of the command using command id.

HTTP Request

GET /v1/command/:id.xml

Parameters

Parameter Default Description
apiKey obligatory API key.
sessionId obligatory Session identifier.
sessionIdSignature obligatory Signature preventing session id enumeration by attacker.
:id obligatory Command identifier as part of the URL.

Data returned

See on the right pane how the data structure looks like per command status.

For a detailed description of <result> content see the documentation of the relevant commands in the advanced API.

Command states table:

State Description
setup command is queued and is awaiting allocation of resources
in_progress command is scraping data from online transaction system
successful the command has successfully executed. All data imported by the command is contained inside <result> tag.
cancelled the command has been cancelled by the service client
error command execution failed to complete due to: 1) errors beyond Kontomatik control (i.e. expired session with transaction system, target transaction system is experiencing some technical problems) 2) client induced errors (i.e. problems with network connection/proxy, invalid bank account number, unsupported command for a given target). The <exception> element contains error details. Errors should not be reported to Kontomatik.
fatal a bug in Kontomatik software. If you use our hosted service we will learn about all fatal errors automatically. If you host Kontomatik on your servers you should report all fatals to us, including the full reply content (among other things, it will contain the stacktrace).

Error handling

We can divide possible errors into four categories:

Errors caused by external factors

Command execution may fail due to causes beyond our control. Temporary unavailability of the bank and expired sessions are just two examples of what can go wrong.

Exception Description
IOException Network issue between Kontomatik and bank occured. For example the bank failed to respond in a timely manner. What to do: retry command that failed up to 3 times, then give up and ask user to try again later.
SessionExpired The session with the online transaction system has expired. What to do: ask the user to try again (show the widget step) and to not use the bank manually at the same time as parallel sessions can kill each other.
ConcurrentSessionsLimitExceed User has not signed out and second session cannot be started until the abandoned one expires. What to do: ask the user to try again (show the widget step) in a few hours.
ServiceTemporarilyUnavailable Online transaction system is temporarily unavailable. What to do: ask the user to try again in a few minutes because his online banking is temporarily unavailable.
ServiceMaintenance Online transaction system under maintenance. What to do: ask the user to try again in a few hours because his online banking is undergoing planned maintenance.

API integration errors

Response (example)

<?xml version="1.0" encoding="utf-8"?>
<reply status="404 Not Found">
  <exception name="InvalidCommandId">
  </exception>
</reply>

If you get one of these errors you should review your API client code for integration issues. These errors can be caused by numerous factors, like passing invalid params or failure to pass all required params.

Exception Description
CommandNotAvailable The command is not available for the selected target
InvalidCommandId Invalid command identifier
InvalidOwnerExternalId Invalid identifier of the data owner
NotSignedIn Only signed-in user can call the command
AlreadySignedIn You cannot sign-in twice in the same session - start a new session
InvalidIban Invalid bank account number (e.g. empty, incorrect syntax)
InvalidTarget Invalid target identifier
InvalidSessionId Invalid session identifier
InvalidSessionIdSignature One or both of sessionId and sessionIdSignature passed parameters were malformed
InvalidSince Invalid start date
JobsQuotaExceeded Your app has started too many imports simultaneously. What to do: wait for 10-15 seconds to allow some of the imports to finish and resubmit the command. If you get the same error, repeat the process until the command is accepted.

Bugs in Kontomatik

The following should be considered bugs in the Kontomatik Service. Most likely, some edge case condition occured and our software was not prepared for this. Kontomatik should be improved to cover this case. You may want to excuse your user and redirect him to the other path.

In case of a SaaS deployment we will be automatically notified so you don’t have to take any action. In case of self-hosting these errors should be reported to api@kontomatik.com, attaching the XML reply and logs of the application server.

There are two scenarios to consider:

HTTP response status code >= 500

As with any HTTP service, it is a good practice to properly handle occasional server hard fails like '500 Internal Server Error’ or '503 Service Unavailable’.

Simply check for the HTTP response status code. Of course, don’t assume XML body in this case.

Unexpected async command failure

You will learn about this error after polling for command status and noticing the fatal command state:

Please note that the HTTP response status code will be still '200 OK’ because your query for the command status worked fine. It is only the asynchronous command that failed earlier.

Exception Description
KontoXBug Unhandled condition occured. What to do: in a SaaS deployment you don’t have to do anything. We get notified and you can expect the bug will be resolved in a timely manner. In on-premises deployments you should send us the whole XML response (which will include the stacktrace).

Errors caused by the end-user

These errors are a “fault” of the end user. The SignIn Widget will handle it by kindly asking the user to resolve his issues and try again. You do not have to do anything.

Exception Description
AccessBlocked Access to the account is blocked. What to do: ask the user to call his bank and unblock his online access.
AccessTemporarilyBlocked Access to the account is temporarily blocked and expected to auto-unlock. What to do: ask the user to try again in a few hours.
ManualActionRequired A manual action in the online transaction system is required (e.g. accepting changes in terms of use). What to do: ask the user to manually log into the bank and take care of all pop-ups, new terms of use etc.
InvalidCredentials End user entered invalid credential. What to do: let the user try again entering credentials.
UnsupportedLoginMethod This login scenario is not supported. What to do: ask the user to login in a more standard way.
UnsupportedLanguage The language of the bank UI is not supported. What to do: ask the user to change the bank online UI locale to the default one.
InsufficientIdentificationLevel The user has opened the account anonymously from his mobile phone and because of this, identification data is missing or cannot be validated. This error can only occur for the target Webmoney_ru.

Lending API

Lending API is a perfect fit for small and medium lenders.

It allows you to take full advantage of the raw banking data in an easy way.

The lending API offers the Financial Health Indicator and a set of values aggregated over end-user’s banking data.

The lending API returns the calculations immediately. It works on the data you imported earlier. Be sure to import the data first, otherwise lending APIs will always return zeros.

The lending API will work with both screen-scraped data and parsed-PDF data.

Financial Health Indicator

Request

curl --get \
  --data "apiKey=YOUR_LONG_API_KEY_HERE" \
  --data "ownerExternalId=END_USERS_OWNER_EXTERNAL_ID" \
  https://test.api.kontomatik.com/v1/indicator.xml

Response

<?xml version="1.0" encoding="utf-8"?>
<reply status="200 OK">
  <indicator>
    <value>87</value>
    <distribution>
      <period>
        <days>7</days>
        <startAt>YYYY-MM-DD HH:MM:SS</startAt>
        <endAt>YYYY-MM-DD HH:MM:SS</endAt>
      </period>
      <average>49.07</average>
      <median>51.00</median>
    </distribution>
  </indicator>
</reply>

Financial Health Indicator (FHI) is a single 0-100 number aiming to roughly assess end-user bank accounts’ trustworthiness (the more, the better).

FHI is solely based on end-user’s banking data. Presently it does not take into account any other factors.

Among other things, we take into account average monthly income, total balance, bank accounts reliability (how old and rich in data the accounts are), the sum of loans granted by other lenders, etc.

Details of the algorithm are proprietary and evolving.

This command does not import any data by itself, it just uses data imported by other commands for a given end-user (i.e. import accounts, import transactions commands).

It’s essential to wait for the import commands to finish before requesting GET /v1/indicator.xml, otherwise the algorithm will work on partial data and produce unreliable results.

This request also returns a distribution of FHI values based on all previous data stored in our service. This may work as a base for your threshold and will change as we adjust our FHI algorithms.

HTTP Request

GET /v1/indicator.xml

Parameters

Parameter Default Description
apiKey obligatory API key.
ownerExternalId obligatory Your identifier for the end user, that you passed as one of the parameters to Kontomatik Sign-in widget.

Data returned

FHI value is store in “value” tag of “indicator” tag. Indicator distribution data is being wrapped in “distribution” tag.

Data Availability Description
value guaranteed FHI value.
distribution guaranteed Container for distribution data.

Distribution data:

Data Availability Description
period guaranteed Container for “day”, “startAt” and “endAt” fields.
days guaranteed Describes how many days are being taken into account for counting distribution. It’s usually 7.
startAt guaranteed Start date of distribution counting period. It’s in YYYY-MM-DD HH:MM:SS format.
endAt guaranteed End date of distribution counting period. It’s in YYYY-MM-DD HH:MM:SS format.
average guaranteed Average value of all FHI values.
median guaranteed Median of all FHI values.

Aggregated Values

Request

curl --get \
  --data "apiKey=YOUR_LONG_API_KEY_HERE" \
  --data "ownerExternalId=END_USERS_OWNER_EXTERNAL_ID" \
  --data "periodMonths=6" \
  https://test.api.kontomatik.com/v1/aggregates.xml

Response

<reply status="200 OK">
  <owner externalId="123456">
    <target name="MBank">
      <accounts>
        <account>
          <iban>PL49114020040000350243107620</iban>
          <activeSinceAtLeast>2014-03-03</activeSinceAtLeast>
          <currencyName>PLN</currencyName>
          <owner>Jan Kowalski</owner>
          <months>
            <month date="2014-03">
              <daysInMonth>31</daysInMonth>
              <withdrawalsCount>2</withdrawalsCount>
              <withdrawalsTotal>32.50</withdrawalsTotal>
              <depositsCount>2</depositsCount>
              <depositsTotal>32.50</depositsTotal>
              <balance>64.50</balance>
              <balanceAverage>24.50</balanceAverage>
              <positiveBalanceAverage>24.50</positiveBalanceAverage>
              <negativeBalanceAverage>-24.50</negativeBalanceAverage>
              <maxBalance>90.50</maxBalance>
              <minBalance>-90.50</minBalance>
              <!-- Aggregates specific to Poland -->
              <polishZusTransactionsCount>1</polishZusTransactionsCount>
              <polishZusTransactionsTotal>10000.00</polishZusTransactionsTotal>
              <polishUsTransactionsCount>1</polishUsTransactionsCount>
              <polishUsTransactionsTotal>10000.00</polishUsTransactionsTotal>
            </month>
            <!-- ...more months... -->
          </months>
        </account>
      </accounts>
    </target>
  </owner>
</reply>

Calculates and returns aggregates for end-user identified by ownerExternalId parameter passed when embedding the Kontomatik Sign-in widget.

Imported data is grouped by accounts and a monthly summary statistics is calculated (i.e. number of withdrawals, balance average) for each of the accounts.

The length of the period for which the aggregates are calculated is determined by the value of periodsMonth parameter.

This command does not import any data by itself, it just uses data imported by other commands for a given end-user (i.e. import accounts, import-transactions commands).

HTTP Request

GET /v1/aggregates.xml

Parameters

Parameter Default Description
apiKey obligatory API key.
ownerExternalId obligatory Your identifier for the end-user, that you passed as one of the parameters to Kontomatik Sign-in widget.
periodMonths obligatory Period in months that the aggregates will be calculated for, including current month.

Data returned

See on the right pane what the data structure looks like.

Each <target> element contains a collection of accounts opened in a given bank (name attribute holds an Kontomatik’s internal code for the bank). The aggregates are grouped by an account and a month. The <account> tag contains some basic information about the account (for description of the data please consult the summary of import accounts command). Each <month> tag encapsulates the following elements:

Data Availability Description
daysInMonth guaranteed number of days in a given month
withdrawalsCount guaranteed total number of withdrawals from the account
withdrawalsTotal guaranteed value of all withdrawals from the account
depositsCount guaranteed total number of deposits in an account
depositsTotal guaranteed value of all deposits in an account
balance available except for exceptional cases account balance at the end of month
balanceAverage available except for exceptional cases average monthly account balance
positiveBalanceAverage possibly none average account balance for days with balance over 0 monetary units
negativeBalanceAverage possibly none average account balance for days with balance below 0 monetary units
maxBalance available except for exceptional cases maximum daily closing balance in a given month
minBalance available except for exceptional cases minimum daily closing balance in a given month
polishZusTransactionsCount possibly none total number of transactions from/to Polish Social Insurance Institution (ZUS)
polishZusTransactionsTotal possibly none net value of all transactions from/to Polish Social Insurance Institution (ZUS)
polishUsTransactionsCount possibly none total number of transactions from/to Polish Internal Revenue Service
polishUsTransactionsTotal possibly none net value of all transactions from/to Polish Internal Revenue Service

Transaction Labeling

<moneyTransactions>
  <moneyTransaction>
    <!-- ...transaction details... -->
    <labels>
      <label>monthly</label>
      <label>repayment</label>
    </labels>
  </moneyTransaction>
  <moneyTransaction>
    <!-- ...transaction details... -->
    <labels>
      <label>health</label>
    </labels>
  </moneyTransaction>
  <moneyTransaction>
    <!-- ...transaction details... -->
    <labels>
      <label>gambling</label>
    </labels>
  </moneyTransaction>
  <moneyTransaction>
    <!-- ...transaction details... -->
    <labels>
      <label>loan</label>
    </labels>
  </moneyTransaction>
</moneyTransactions>

Labels provide additional data about transactions, to help a lender better understand his customer and quickly assess his financial status.

Using the meta information contained in labels, it is possible to group together transactions and highlight trends across different dimensions, such as overall revenue, loans, health and living expenses, recurrent financial obligations or even internal transfers between the user’s accounts. Red-flagging risk conditions such as gambling is also available.

We developed the feature by consulting with lenders and specifically for risk assesment. Thus transactions labeling is significantly different from categorization, which is simply an attempt to classify transactions according to an arbitrary set of rules - often conceived by the end user. We chose this particular set of labels to highlight transactions, which are crucial for users budget.

HTTP Request

If the feature is activated for your account the transactions will simply come labeled. There is no labeling API call.

Labels will be present in the result of any command that returns transactions such as default-import or import-transactions. For optimal results it is best to fetch all of the owner’s data. This way, the full context of the user’s transactions and accounts will be available to the labeling engine.

Data returned

The following table describes the currently supported labels. Please note that we have not deemed it necessary to mark transactions as income or spending. This basic distinction can be made based on the negative or positive value of <currencyAmount> field.

Label Description
internal transactions determined to be made between accounts owned by the transaction owner. It includes both transactions from saving accounts and household money management
loan transactions related to receiving a loan
repayment transactions that represent a repayment of a credit, loan, credit card or any other kind of debt
monthly transactions that repeat monthly
living transactions that are every day expenses. Like food, clothes, basic services, etc.
fixed periodic fixed payments related to long-term financial obligations, like mortgage, rent, university fees
overdraft every transactions with negative account balance
gambling expenses on gambling portals, casinos or lottery tickets
health expenses like hospital bills, pharmacy and generally related to persons health
tax any transfers related to tax payments, excise, duty, transfers for tax offices, etc.
media payments on media, like TV, phone, internet
welfare transactions which are government’s financial help, like pension
premium transactions related to automatic-payment services, like Uber, Netflix
phone transactions related to phone, like phone bill, pre-payed code, etc.
atm withdrawals from ATM
salary revenue from any kind of work
verification transactions that are a personal data verification. Some organizations use this method to verify users authenticity before granting a loan
debt collection transactions that are executed by debt collector without any action from account owner
500+ specific welfare benefit transaction used only in Poland
interests transactions which are interests from any kind of financial instruments

Advanced API

Tutorial

Please get API access if you haven’t done so already.

Follow this if you need a full controll over the data import process and flow. If you just want to get key data quickly see the basic tutorial.

The first step is to embed the SignIn Widget on your website. Kontomatik SignIn widget takes care of asking the end user for bank credentials and logging into the bank on the user’s behalf.

Catalog

Request

curl --get \
  --data "apiKey=YOUR_LONG_API_KEY_HERE" \
  --data "country=pl" \
  --data "favicons=false" \
  https://test.api.kontomatik.com/v1/catalog.xml

Response

<?xml version="1.0" encoding="utf-8"?>
<reply status="200 OK">
  <targets>
    <target name="" officialName="BOŚ Bank">
      <commands>
        <command name="EnterCredentialCommand"/>
        <command name="ImportAccountTransactionsCommand"/>
        <command name="ImportAccountsCommand"/>
        <command name="ImportOwnersDetailsCommand"/>
      </commands>
      <favicon imageFormat="image/x-icon">
        AAABAAMAE...AAAAA=
      </favicon>
    </target>
    <!-- ... more targets ... -->
  </targets>
</reply>

Returns a list of supported banks and a list of available commands for each bank.

Both of the supported banks and available commands lists are dynamical, so it is recommended not to hard-code them into the implementation of the client to Kontomatik. The client should request the catalog whenever a list of banks or commands is needed.

HTTP Request

GET /v1/catalog.xml

Parameters

Parameter Default Description
apiKey obligatory API key.
country pl Filters banks by the country they operate in. The parameter is case insensitive and uses two letter country codes as defined by the ISO 3166-1 standard. The default value is pl; to display banks available in all supported countries use all value for the parameter.
favicons false Controls whether the catalog should return banks’ favicons. If you are using Kontomatik Sign-in Widget then it is strongly recommended not to use this feature in order to save on bandwith.

Data returned

Description of <target> element:

Attribute Description
name an internal identifier for the bank
officialName full bank name

Description of <command> element:

Attribute Description
name holds command’s formal name; by searching the catalog you can check if the given functionality (e.g. owners’ details import) is available for a given bank

The <favicon> element is displayed only if the favicons parameter was set to true. The tag holds base64 encoded bytes of the bank’s favicon. The imageFormat attribute indicates the image format of the favicon.

Import Owners (command)

Request

curl -X POST \
  --data "apiKey=YOUR_LONG_API_KEY_HERE" \
  --data "sessionId=999999" \
  --data "sessionIdSignature=ffff....ffff" \
  https://test.api.kontomatik.com/v1/command/import-owners.xml

Response

<reply status="202 Accepted">
  <command id="653643" state="in_progress" name="ImportOwnersCommand">
  <progress><value>0</value></progress>
  </command>
</reply>

Final result of polling for this command status

<?xml version="1.0" encoding="utf-8"?>
<reply status="200 OK">
  <command id="653643" state="successful" name="ImportOwnersCommand">
    <progress><value>1</value></progress>
    <result>
      <owners>
        <owner>
          <kind>OWNER</kind>
          <name>Jan Witkacy Kowalski</name>
          <address>Krótka 8, Wąchock</address>
          <polishPesel>82012905123</polishPesel>
          <polishNip>1258882345</polishNip>
          <phone>694234567</phone>
          <email>jan.kowalski@wachock-mail.pl</email>
          <citizenship>Kazakhstan</citizenship>
          <nationality>Polskie</nationality>
          <personalDocumentType>Passport</personalDocumentType>
          <personalDocumentNumber>FGH123456</personalDocumentNumber>
          <birthDate>1960-02-29</birthDate>
          <polishRegon>121260111</polishRegon>
        </owner>
      </owners>
    </result>
  </command>
</reply>

Initiates import of a bank account’s owners and co-owners. The command aims to return all possible details about every owner. In contrast to the import-accounts this command takes data from the global settings/profile rather than from the individual sub-accounts.

The command is asynchronous and it returns command id. Use this call to poll for command status and to fetch results once the command is done.

HTTP Request

POST /v1/command/import-owners.xml

Parameters

Parameter Default Description
apiKey obligatory API key.
sessionId obligatory Session identifier.
sessionIdSignature obligatory Security parameter to prevent session enumeration.

Data returned

Once the command status turns to successful the <result> element will be present containing a list of owners.

See on the right pane how the data structure looks like.

TODO: add missing attributes we support

Data Availability Description
kind guaranteed one of: “OWNER”, “CO_OWNER, "COMPANY”
name guaranteed name (name and surname or company’s name)
address possibly none address
polishPesel possibly none Polish PESEL number
polishNip possibly none Polish NIP number
phone possibly none phone
email possibly none e-mail
citizenship possibly none citizenship
nationality possibly none nationality
personalDocumentType possibly none identity document type, as presented by the bank
personalDocumentNumber possibly none identity document number
birthDate possibly none date of birth
polishRegon possibly none Polish REGON number
birthPlace possibly none Place of owner’s birth

Import Accounts (command)

Request

curl -X POST \
  --data "apiKey=YOUR_LONG_API_KEY_HERE" \
  --data "sessionId=999999" \
  --data "sessionIdSignature=ffff....ffff" \
  https://test.api.kontomatik.com/v1/command/import-accounts.xml

Response

<reply status="202 Accepted">
  <command id="653643"/>
</reply>

Final result of polling for this command status

<?xml version="1.0" encoding="utf-8"?>
<reply status="200 OK">
  <command id="653643" state="successful" name="ImportAccountsCommand">
    <progress><value>1</value></progress>
    <result>
      <accounts>
        <account>
          <name>eKONTO</name>
          <iban>PL32114020040000320250132522</iban>
          <currencyBalance>1467.39</currencyBalance>
          <currencyFundsAvailable>1407.39</currencyFundsAvailable>
          <currencyName>PLN</currencyName>
          <owner>Jan Kowalski, Adam Nowak</owner>
          <activeSinceAtLeast>2000-02-28</activeSinceAtLeast>
          <directDebit available="true"/>
        </account>
        <!-- ... more accounts ... -->
      </accounts>
    </result>
  </command>
</reply>

Initiates import of bank accounts.

The command is asynchronous and it returns command id. Use this call to poll for command status and to fetch results once the command is done.

HTTP Request

POST /v1/command/import-accounts.xml

Parameters

Parameter Default Description
apiKey obligatory API key.
sessionId obligatory Session identifier.
sessionIdSignature obligatory Security parameter to prevent session enumeration.
fast true Disable the fast mode to get a bit more data about the owner in some banks. Be careful, as this adds a considerable time overhead for most banks. If you disable the fast mode you are much more likely to get the owner’s address on top of the owner’s name. Also see the returned data description below.

Data returned

Once the command status turns to successful the <result> element will be present containing a list of accounts.

See on the right pane how the data structure looks like.

Data Availability Description
name guaranteed official account name, as shown in the bank’s transaction system
iban guaranteed full account number (with country code for 'true’ IBAN accounts)
currencyBalance guaranteed current account balance in an account’s currency (it can be different than the currency of the country in which the bank is located in)
currencyFundsAvailable available except for exceptional circumstances equals to the balance being at user’s immediate disposal (it can be different than the currency of the country in which the bank is located in). Can be lower than currencyBalance field.
currencyName guaranteed currency symbol, e.g. “PLN”
owner available except for exceptional circumstances name of the owner or owners of the account as supplied by the bank system. The information can be scraped either from account details or from outgoing transfers. The field is filled in more than 99% cases. In rare circumstances it can be empty, e.g. all of the following conditions are satisfied: the bank does not present owner in the account details or profile/settings and there were no outgoing transactions found.
activeSinceAtLeast available except for exceptional circumstances the date when the account was opened or the date of the oldest transaction found (but not older than a year if searching for older transactions would substantially affect the execution time of the command
directDebit possibly none marks whether the account supports direct debit or not, using a “true” or “false” value for the available attribute. Direct debit accounts can be safely selected by lenders as the destination account for the loan transfer, while non direct debit accounts are tipically savings accounts that do not accept direct transfers. If there is not enough data to resolve this field, the tag will not be present.

Import Transactions (command)

Request

curl -X POST \
  --data "apiKey=YOUR_LONG_API_KEY_HERE" \
  --data "sessionId=999999" \
  --data "sessionIdSignature=ffff....ffff" \
  --data "iban=PL00000000000000000000000000" \
  --data "since=2015-12-01" \
  https://test.api.kontomatik.com/v1/command/import-account-transactions.xml

Response

<?xml version="1.0" encoding="utf-8"?>
<reply status="202 Accepted">
  <command id="653643" state="in_progress" name="ImportAccountTransactionsCommand">
    <progress><value>0</value></progress>
  </command>
</reply>

Final result of polling for this command status

<?xml version="1.0" encoding="utf-8"?>
<reply status="200 OK">
  <command id="653643" state="successful" name="ImportAccountTransactionsCommand">
    <progress><value>97</value></progress>
    <result>
      <moneyTransactions>
        <moneyTransaction>
          <transactionOn>2012-06-28</transactionOn>
          <bookedOn>2012-06-30</bookedOn>
          <currencyAmount>20.00</currencyAmount>
          <currencyBalance>230.00</currencyBalance>
          <title>Return for beer in a pub</title>
          <party>Jan Kowalski</party>
          <partyIban>PL68249000050000400075212326</partyIban>
          <kind>EXTERNAL INCOMING TRANSFER</kind>
          <labels>
            <label><!-- label type --></label>
            <!-- ... more labels ... -->
          </labels>
        </moneyTransaction>
        <!-- ... more transactions ... -->
      </moneyTransactions>
    </result>
  </command>
</reply>

Initiates import of transactions for the selected bank account and period.

The command is asynchronous and returns command id. Use this call to poll for command status and to fetch results once the command is done.

HTTP Request

POST /v1/command/import-account-transactions.xml

Parameters

Parameter Default Description
apiKey obligatory API key.
sessionId obligatory Session identifier.
sessionIdSignature obligatory Security parameter to prevent session enumeration.
iban obligatory Full account number of the account for which the list of transactions should be fetched. Preferably, use the iban value returned by the import-accounts command.
since obligatory Start date in YYYY-MM-DD format. Only transactions that occurred on or after the since date will be imported.

Data returned

Once the command status turns to successful the <result> element will be present containing a list of transactions.

See on the right pane how the data structure looks like.

Data Availability Description
transactionOn guaranteed actual transaction date
bookedOn guaranteed transaction’s booking date (sometimes even 10 days after the transactionOn). In exceptional circumstances, transaction date or value date will be assigned to this attribute
currencyAmount guaranteed transaction amount expressed in account’s currency (it can be different than the currency of the country in which the bank is located)
currencyBalance possibly none account balance expressed in account’s currency
partyIban guaranteed for transactions with a non-empty party attribute full account number of the other party of the transaction. The field is always available for transfers between accounts. For some transactions (i.e. payments by debit/credit card, bank fees and commissions) the account number is unavailable.
party possibly none the name of the other party of the transaction is always available. For some transactions (i.e. contra-entry type transactions) the name of the other party is unavailable.
title possibly none transaction title
kind possibly none transaction type, as presented in the online transaction system (e.g. “INTEREST COMPOUNDING”)
labels possibly none list of transaction’s labels. See Transaction labeling for more information

Import Credit Cards (command)

POST /v1/command/import-credit-cards.xml

Initiates import of credit cards’ details. The command is synchronous and returns the command id. Use this call to poll for command status and to fetch results once the command is done.

<reply status="202 Accepted">
  <command id="653643"/>
</reply>
Parameter Default Description
apiKey obligatory API key.
sessionId obligatory Session identifier.
sessionIdSignature obligatory Security parameter to prevent session enumeration. 
<!-- inside the result tag -->
  <creditCards>
    <creditCard>
      <name>Visa</name>
      <number>1234 1234 1234 1234</number>
      <currencyBalance>-2467.39</currencyBalance>
      <currencyName>PLN</currencyName>
      <owner>Jan Kowalski, Adam Nowak</owner>
      <limit>5000.00</limit>
      <interest>20</interest>
      <dueDate>2013-10-26</dueDate>
    </creditCard>
    <!-- ... more credit cards ... -->
  </creditCards>
<!-- the end of the result tag -->
Data Availability Description
name guaranteed card name, as stated in the bank’s system
number guaranteed card number, as presented in the bank’s system. Vast majority of the banks present credit card number with most significant digits replaced with asterisks, just a few banks present unmasked credit card number. Use this number when importing money transactions associated with the given credit card.
currencyBalance guaranteed current credit card balance in card’s currency (it can be different than the currency of the country which the bank is located in)
currencyFundsAvailable possibly none the amount of available credit in card’s currency (it can be different than the currency of the country which the bank is located in)
currencyName guaranteed currency symbol, e.g. “PLN”
owner possibly none name of the credit card holder, as presented in the online transaction system
limit possibly none credit limit as a positive number
interest possibly none card’s interest rate, expressed in percentage
dueDate possibly none the day the payment is due; date format: YYYY-MM-DD

Import Credit Card Transactions (command)

POST /v1/command/import-credit-card-transactions.xml

Initiates import of money transactions associated with a given credit card. The command is synchronous and returns the command id. Use this call to poll for command status and to fetch results once the command is done.

<reply status="202 Accepted">
  <command id="653643"/>
</reply>
Parameter Default Description
apiKey obligatory API key.
sessionId obligatory Session identifier.
sessionIdSignature obligatory Security parameter to prevent session enumeration.
since obligatory start date in YYYY-MM-DD format, only transactions that occurred on or after the since date will be imported
cardNumber obligatory identifies the credit card for which the transactions should be fetched. Preferably, use the number value returned by the import-credit-cards command. 
<!-- inside the result tag -->
  <moneyTransactions>
    <moneyTransaction>
      <id>666</id>
      <transactionOn>2012-06-28</transactionOn>
      <bookedOn>2012-06-30</bookedOn>
      <currencyAmount>20.00</currencyAmount>
      <title>Return for beer in a pub</title>
      <party>Jan Kowalski</party>
      <partyIban>PL68249000050000400075212326</partyIban>
      <kind>INCOMING EXTERNAL TRANSFER</kind>
    </moneyTransaction>
    <!-- ... more transactions ... -->
  </moneyTransactions>
<!-- the end of the result tag -->
Data Availability Description
transactionOn guaranteed transaction date; in some cases the attribute will be assigned with another date, e.g. currency date
bookedOn guaranteed transaction’s booking date (sometimes even 10 days after the transactionOn); in some cases this field will be assigned with currency date or transaction date if booking date is missing
currencyAmmount guaranteed transaction amount in an card’s currency (it can be different than the currency of the country which the bank is located in)
title possibly none transaction title
party possibly none the name of the other party of the transaction
partyIban possibly none full account number of other party of the transaction
kind possibly none type of transaction, just as it is presented in the online transaction system (e.g. “INTEREST COMPOUNDING”)

Sign Out (command)

Request

curl -X POST \
  --data "apiKey=YOUR_LONG_API_KEY_HERE" \
  --data "sessionId=999999" \
  --data "sessionIdSignature=ffff....ffff" \
  https://test.api.kontomatik.com/v1/command/sign-out.xml

Response

<reply status="200 OK">
</reply>

Synchronous command that logs out of the bank’s transaction system. Given that the bank supports the sign out command, it is advised to log out of the bank’s transaction system once you have imported all data to prevent blocking of the system for the end user.

HTTP Request

POST /v1/command/sign-out.xml

Parameters

Parameter Default Description
apiKey obligatory API key.
sessionId obligatory Session identifier.
sessionIdSignature obligatory Security parameter to prevent session enumeration.

HTTP Response

An empty xml is returned - please see in the right pane what the response looks like.

Cancel command

Request

curl -X POST \
  --data "apiKey=YOUR_LONG_API_KEY_HERE" \
  https://test.api.kontomatik.com/v1/command/YOUR_COMMAND_ID_HERE/cancel.xml

Response

<reply status="202 Accepted">
</reply>

Cancels command execution. The command is asynchronous. If the command is in the in_progress state, it will be cancelled before making another request (still, the current request has to end). A cancelled command cannot be resumed.

Cancelling is useful if it is necessary to provide the user with the ability to stop an action. When a command is cancelled the working thread is released back into the pool, optimizing resource usage.

After cancelling a command it is recommended to create a new session, if the import from a given target is to be continued. Cancelling a command can leave the http agent’s library in an inconsistent state, causing errors while executing other commands within the same session.

HTTP Request

POST /v1/command/COMMAND_ID/cancel.xml

Parameters

Parameter Default Description
apiKey obligatory API key.

Data

Request

curl --get \
  --data "apiKey=YOUR_LONG_API_KEY_HERE" \
  --data "ownerExternalId=END_USERS_OWNER_EXTERNAL_ID" \
  https://test.api.kontomatik.com/v1/data.xml

Response

<reply status="200 OK">
  <owner externalId="653643">
    <target name="MBank">
      <owners>
        <owner>
          <name>Jan Kowalski</name>
          <address>Kwiatowa 8/97 Warszawa  PL</address>
          <polishPesel>84011806651</polishPesel>
          <phone>+48612***078</phone>
          <email>jankowalski@xgmail.com</email>
          <citizenship>PL</citizenship>
          <personalDocumentType>Identity document</personalDocumentType>
          <personalDocumentNumber>AAB123456</personalDocumentNumber>
          <birthDate>1984-01-18</birthDate>
          <birthPlace>Warsaw</birthPlace>
          <kind>OWNER</kind>
        </owner>
        <!-- ... more owners ... -->
      </owners>
      <accounts>
        <account>
          <name>eKONTO</name>
          <iban>PL32114020040000320250132522</iban>
          <currencyBalance>1467.39</currencyBalance>
          <currencyFundsAvailable>1407.39</currencyFundsAvailable>
          <currencyName>PLN</currencyName>
          <owner>Jan Kowalski, Adam Nowak</owner>
          <activeSinceAtLeast>2000-02-28</activeSinceAtLeast>
          <moneyTransactions>
            <moneyTransaction>
              <transactionOn>2012-06-28</transactionOn>
              <bookedOn>2012-06-30</bookedOn>
              <currencyAmount>20.00</currencyAmount>
              <currencyBalance>443.00</currencyBalance>
              <title>Return for beer in a pub</title>
              <party>Jan Kowalski</party>
              <partyIban>PL68249000050000400075212326</partyIban>
              <kind>EXTERNAL INCOMING TRANSFER</kind>
              <uid>2012-06-30__20.00</uid>
                <labels>
                  <label><!-- label type --></label>
                  <!-- ... more labels ... -->
                </labels>
            </moneyTransaction>
            <!-- ... more transactions ... -->
          </moneyTransactions>
        </account>
        <!-- ... more accounts ... -->
      </accounts>
    </target>
  </owner>
</reply>

Returns all imported and aggregated data associated with the end user identified by an ownerExternalId parameter passed when embedding the Kontomatik Sign-in widget.

Response can take up to several seconds and potentially it may return lots of data (thousands of transactions) depending on the end user’s activity.

HTTP Request

GET /v1/data.xml

Parameters

Parameter Default Description
apiKey obligatory API key.
ownerExternalId obligatory Your identifier for the end user, that you passed as one of the parameters to Kontomatik Sign-in Widget.
only optional Filters the results returned by the data type. You can pass one of the following values: owners, accounts, transactions.

Data returned

Each <target> tag contains all data imported for the end user from a given bank. A sample response is provided on the right pane. If you closely examined the structure of the xml then you probably had noticed that the <target> encapsulates the data structures returned by import accounts and owner details commands. Furthermore, the <account> tag contains a list of transactions associated with the given account.

For a detailed description of data structures encapsulated by the <owners>, <accounts> and <moneyTransactions> tags, please consult the descriptions of the related commands.

Delete data

HTTP Request

DELETE /v1/owner.xml

curl -X DELETE --data-urlencode "apiKey=YOUR_API_KEY_VALUE"\
              --data-urlencode "ownerExternalId=222222"\
               https://test.api.kontomatik.com/v1/owner.xml


<reply status="200 OK">
</reply>

Deletes all imported and aggregated data associated with the end user identified by an ownerExternalId parameter passed when embedding the Kontomatik Sign-in widget.

Parameter Default Description
apiKey obligatory API key.
ownerExternalId obligatory Your identifier for the end user, that you passed as one of the parameters to Kontomatik Sign-in Widget.

Health Check

Request

curl --get \
  https://test.api.kontomatik.com/isItWorking

Response

I am working.

Used to ensure that Kontomatik server is up.

This is the only request that does not require the API key.

HTTP Request

GET /isItWorking

Data returned

The request should response with a plain text “I am working.”.

Testing

You don’t need to own a bank account in all banks to test your integration with Kontomatik Service.

Kontomatik Service offers mock (example) responses for all commands in all banks.

To use it simply enter “test” as first credential, then “Test123” for each of the following passwords.

In exceptional cases:

By using test credentials the session gets internally marked as a testing session and example (hardcoded) data are returned instead of connecting to banks. That being said one small request to the bank is made just to check connectivity.

Getting help

Technical questions or issues should be submitted to Kontomatik Support Channel api@kontomatik.com.

To investigate incomplete or incorrect API responses, we need a sessionId or commandId value. Please include one of them in your email, along with a short description of the issue.

The following unofficial projects offer additional help to developers.

Kontomatik-help-kit simplifies the process of manually importing data from terminal, using curl. The kit contains a index.html page embedding the Sign-In Widget and simple shell scripts which build and submit the Http requests corresponding to the main API methods.

KontomatikServiceDemo is an example web application with a backend Kontomatik API client implemented in .NET.

code