Credentials

API keys

We have OAuth 2.0 client credentials implemented as our authentication mechanism, as described in further detail on this page. Application key (fixed), client key (unique for the client integration instance) and subscription key (fixed) are used to get an access token from our server (and the demo and producting servers are completely separate with different sets of keys). The access token is unique for the client key and thus the given client. With the access token, api requests can be made to retrive from or send data to the given client, depending on the authorization (acces priveliges).

In this way the client key is regarded as a password, and should be treated as such. Avoid exposing the client key in places where other parties can see it - it should preferably be stored in a secure place, and encoded in a non-human readable form. In our end, once a client activates a given integration on their Go client, creating a new client key, we will only display the key in the initial dialogue. Following activation, the key is encrypted using salt and hash functions and is not retrievable by us.

Onboarding

The most secure and "market-friendly" way of exchanging the client key, is currently to implement our onboarding solution as described here. This allows you to dedicate a process of onboarding the Go client from your application or website, retrieving the client key(s) programmatically if the process is successful

Handling the access tokens

The client keys must be stored in a secure manner, and this applies for the unique access tokens as well. We recommend securely storing the key in a repository and encourage you to carefully consider the technological components used for multithreaded processes. This is especially important if your integration will be used by multiple clients and as such will be handling multiple access tokens. We have experienced instances of certain technical components that are configured to share repositories by default in multithreaded processes, which can create a risk of data leakage between Go clients if not managed correctly (e.g., through reprogramming of the component).

It is your responsibility to ensure the correct and secure handling of credentials and access tokens, regardless of the setup of your external system and technology used. Misusing access tokens and inadvertently accessing or transmitting data to incorrect clients can have significant consequences for those clients. As such, we must emphasise the importance of awareness regarding this issue.