The Kurtosys API platform is a SAAS platform that automates the digital marketing workflow for asset managers. Our APIs allow developers to build solutions around our stack, and this documentation is targeted at those developers working on the platform, explaining the basic concepts as well as providing a quick start guide.
At the core of the Kurtosys platform we track all the data elements associated with funds and share classes: fund facts, allocations, statistics, price histories, and documents. We also track associated information, such as registered for sale lists, translations, disclaimers, fund commentaries, fund manager data with associated pictures.
This data is created and retrieved using a series of high speed webservices, operating on
At its core is a maleable data model, with 'Properties' defining how each client's data model should look. Once property definitions are in place, data can be inserted using JSON objects, sent either via HTTPS or secure web socket (WSS). When the data is sent, it is checked against these properties and validated.
Data can be retrieved via the service layer too. The search services expose other functionality, such as data stitching, translation, filter, sorting, and formatting.
The first thing you will need when working with the platform is an account to access the system. Your representative at Kurtosys can create this for you and will usually provide you with a username and a password to access the system. This username and password should be kept secret as it affords access to the whole of your account.
Once you have your username and password, try logging in to the system. The full authentication docs can provide you with details on how to do this.
Once you've logged in you will receive a security token, which should allow you to perform more interesting activities in the system. It should be passed as either the X-KSYS-TOKEN variable of the HTTPS calls, or the token variable of the web socket initiation.
If you are setting up a new asset manager, you will need to setup their data model. This can be done by defining their specific properties.
We use a flexible data model that can be moulded to the needs of an individual asset manager. There are shared concepts exposed in the system, such as funds, share classes, allocations, and statistics, but within each of these 'buckets' the details of what can be stored can be different from client to client.
So for example, if a manager requires the ability to track a series of risk statistics, they can define a new statistic property, perhaps named risk_stats. Within this definition a series of 'virtual columns' can also be defined to track the individual data points desired. The creation of this property ahead of time is crucial, as these definitions are used in the data ingestion services when data is pushed into the system. If for whatever reason, the data presented doesn't match, it is rejected.
To create properties, explore the properties section of the fundpress documentation.
A good first test is to setup a single fund level property in the system, then to try to enter a dummy fund with this property as a data point.
Once you have one or many properties defined, you can start to send data. Note that almost every type of data in the system relates to a share class or fund, so you will need to create these items first. This is because when creating allocations, statistics, historical datasets or timeseries, these data will need to be linked to an existing fund or share class.
To create actual business data, review the documentations for the data loader service.
Once data has been entered, you can view it by using the search services. For fund or share class related data, the searchEntity service can be used. In addition, there is a similar end point for documents searchDocuments.