Entity Loader Service

The entity loader service provides both HTTP and WS endpoints to load client business objects into the Fundpress system.

Table of Contents

General Operations

Loaders accept JSON messages corresponding to the things in the system. For example, consider the following JSON message below representing a share class:

{
    "clientCode": "GB00B4NVSH01",
    "type": "CLSS",
    "propertiesPub": {
        "inception_date": {
            "value": "1994-09-30"
        },
        "aum": {
            "value": 123000000
        },
        "asset_class": {
            "value": "Equity"
        },
        "country_reg_inst": {
            "value": ["LU", "CH"]
        }
    }
}

Posting this message, with an appropriate token, to https://api.fundpress.io/dataloader/upsertentity, all being well, should result in a new share class being created. Passing the same message again would result in an update, with the unique clientCode field being used to identify the correct record to be updated. Note that the unique key used for different types of business object of course varies. For an entity it is the clientCode and the clientId (derived in the service from the user's token). Full keys are detailed in the per service sections below.

Failure of a service should result in an appropriate HTTP code and a description of why the request failed. In most cases this will be enough for the caller to be able to correct their data.

For loading via websocket, creating an array of these JSON messages in a program, establishing a websocket session with wss://api.fundpress.io/dataloader/upsertentity, and passing them all to it should create multiple entries. Full details of the websocket protocol are provided below.

Entity

Entity is used to load fund classes or funds. The full JSON schema can be found by posting {"schema":"entity"} to https://api.fundpress.io/config/schema.

They primary key of an entity is clientCode. This field must be unique across a client's entity's. If you provide the same client code, an update will occur. Make sure you choose a unique value for this (ISIN is a good candidate for share classes).

The type field is used to denote whether we are dealing with a fund (FUND) or share class (CLSS). Note that fundpress is not super opinionated about how each client establishes their data model. For example, usually allocation data is the same across all share classes of the same fund family. Logically then you would assume that all clients would provide a FUND object related to its share classes, and put the Allocation data there (as a Fundpress allocation object). However, in some cases they don't. They simple send the same holdings for each share class and duplicate the data. Fundpress doesnt really care whether you want to do one or the other.

The propertiesPub object is used to store the basic properties of the fund or share classes. This is typically used for static things that don't change very often. The reason for this is that, as with all services, the entity service operates in an upsert fashion, completely overwriting all data in the record when a new upsert is sent. That is to say, if you started with an object like this on day one.

{
    "clientCode": "GB00B4NVSH01",
    "type": "CLSS",
    "propertiesPub": {
        "inception_date": {
            "value": "1994-09-30"
        },
        "aum": {
            "value": 123000000
        },
        "asset_class": {
            "value": "Equity"
        },
        "country_reg_inst": {
            "value": ["LU", "CH"]
        }
    }
}

And then on day two you recieved an updated AUM, you would need to update the whole object, along with the asset class, inception_date, etc… If you didnt provide them all, then the system is going to lose those values. So for example, if you sent in an updated message like this:

{
    "clientCode": "GB00B4NVSH01",
    "type": "CLSS",
    "propertiesPub": {
        "aum": {
            "value": 123000000
        }
    }
}

You are going to lose the inceptiondate, assetclass, and countryreginst values. Our clients have a clear delineation between slow (asset_class, updates never) and fast (price, updates every day). Fast data is usually numeric in nature. As such, a best practice is to pull this out into a statistics object instead of placing it in the fund properties (covered below).

The next thing to note about the properties are that they are governed by a list of legal properties in the system. That is to say, you can't just create an entity wiht a property of "fruit":{"value":"banana"}. To do that you would need to have registered that property with the system using the config service (https://api.fundpress.io/config/addproperty). You can read the full docs there, but suffice to say that you need to specify the data type and code for the property, and when you try to enter an entity, it will type check each provided property before allowing you to enter the data into the system.

Allocations

Allocations are loosely used to track things like top ten holdings, geographic holding aggregations, and other ways of slicing and dicing the fund's holdings for use in charts and graphs. The full JSON schema can be found by posting {"schema":"allocation"} to https://api.fundpress.io/config/schema.

Allocations can be loaded at either https://api.fundpress.io/dataloader/upsertallocations or wss://api.fundpress.io/dataloader/upsertallocations. The same general loading rules apply here for web socket and https (headers, init messages).

The basic structure of an allocation allows us to provide an array of labels ("Japan" for instance) and a numeric value (0.1) for example. The values provided in the labels are completely freeform, unlike properties, so you really could decide to provide the label banana for a geographic holding if you wanted to. Ultimately though, you end up with a list of labels and values that can be used to build charts. Simple.

The structure of the message is as follows

{
    "entityType": "CLSS",
    "clientCode": "LU123123123",
    "code": "geographic_exposures",
    "ccy": "NA",
    "values": [
        {
            "label": "Japan",
            "value": 0.25
        },
        {
            "label": "UK",
            "value": 0.25
        },
        {
            "label": "USA",
            "value": 0.25
        },
        {
            "label": "France",
            "value": 0.25
        }
    ]
}

The primary key of this object is the clientCode (what object it relates to), the code (the AllocationProperty it refers to, because as with core properties, allocations can only be created once they have been registered with Fundpress, using the https://api.fundpress.io/config/addallocproperty method), and finally the currency. The reason we add currency is that sometimes, some of these measures are expressed in multiple currencies. We don't often see this, so if its not needed its fine to use NA instead. Whatever you use for currency, just be consistent, as this is part of the key so it needs to be the same each time for updates to work.

The values, as described above comprise a label and value. Label needs to be a string, value needs to be a number. There are instances where you may require more than a label and a value. Perhaps a top ten fixed income holdings where the duration is included for each holding. In this instance, you can extend the data in these objects with keys of any type. You may end up with something that looks like this:

{
    "entityType": "CLSS",
    "clientCode": "LU123123123",
    "code": "top_ten_bonds",
    "ccy": "NA",
    "values": [
        {
            "label": "IBM",
            "value": 0.25,
            "duration": 1.6
        },
        {
            "label": "GOOG",
            "value": 0.25,
            "duration": 2.6
        },
        {
            "label": "TESLA",
            "value": 0.25,
            "duration": 7.6
        },
        {
            "label": "MICROSOFT",
            "value": 0.25,
            "duration": 0.6
        }
    ]
}

Note that in order to add the duration key, it needs to be registered as part of this allocation property using the configuration service as an extended element. Extended elements can have strong types too, so the system will prevent data coming in if it is not a number / date etc…

Statistics

Statistics are designed to hold collections of numbers pertaining to the funds performance, price, or other metrics that are not time based in nature. The full JSON schema can be found by posting {"schema":"statistic"} to https://api.fundpress.io/config/schema.

Statistics can be loaded at either https://api.fundpress.io/dataloader/upsertstatistics or wss://api.fundpress.io/dataloader/upsertstatistics. Usual conditions apply.

The statistics service is almost identical to the allocations service, as the data is similar in nature. Consider a situation where a fund wants to track its performance stats. You might create an object like this, with an extended property to capture a comparison of the benchmark over a similar period.

{
    "entityType": "CLSS",
    "clientCode": "LU123123123",
    "code": "portfolio_stats",
    "ccy": "NA",
    "values": [
        {
            "label": "Alpha",
            "value": 0.25,
            "benchmark_value": 1.6
        },
        {
            "label": "Beta",
            "value": 0.25,
            "benchmark_value": 2.6
        },
        {
            "label": "Sharpe",
            "value": 0.25,
            "benchmark_value": 7.6
        },
        {
            "label": "Standard Deviatio",
            "value": 0.25,
            "benchmark_value": 0.6
        }
    ]
}

You can see the same key value pairs are used. Alternatively, depending on the requirements you might choose to transpose this to make it easier to work with on the front end

{
    "entityType": "CLSS",
    "clientCode": "LU123123123",
    "code": "portfolio_stats",
    "ccy": "NA",
    "values": [
        {
            "label": "Manager",
            "value": 0,
            "Alpha": 1.6,
            "Beta": 1.6,
            "Sharpe": 3,
            "Sortino": 4
        },
        {
            "label": "MSCI All World",
            "value": 0,
            "Alpha": 1.6,
            "Beta": 1.6,
            "Sharpe": 3,
            "Sortino": 4
        }
    ]
}

This example would require different extended properties to be registered in the system, but might be preferable if there were an indeterminate number of share classes in the comparison, as you can keep adding elements to the values array infinitely.

Timeseries

Timeseries are designed to hold date/value pairs to track how various metrics have changed over time. The full JSON schema can be found by posting {"schema":"timeseries"} to https://api.fundpress.io/config/schema.

Timeseries can be loaded at either https://api.fundpress.io/dataloader/upserttimeseries or wss://api.fundpress.io/dataloader/upserttimeseries. Usual conditions apply.

A typical timeseries object is shown below, again with an extended property of "benchmark_return".

{
    "entityType": "CLSS",
    "clientCode": "LU123123123",
    "code": "quarterend_returns",
    "ccy": "N/A",
    "classification": "N/A",
    "periodicity": "QUARTERLY",
    "values": [
      {
        "date": "1997-12-31",
        "value": 0.15,
        "benchmark_return":"42.2"
      },
      {
        "date": "1997-12-31",
        "value": -0.0413,
        "benchmark_return": 42.2
      },
      {
        "date": "1998-03-31",
        "value": 0.0977,
        "benchmark_return": 42.2
      },

The primary key for a timeseries is the clientCode, the code (governed by a registered timeseries property), a currency (ccy), a classification, and a periodicity. The latter two are introduced because in many cases the same type of timeseries (performance) can be measured at different intervals (monthly vs daily) and also in different ways (net of fees, for instance. Periodicity has a legal list of allowed values (check out its schema for the breakdown) but classification is yours to define. As usual, pay attention to keeping this signature consistent so that your updates and inserts behave consistently.

The values array will contain a date and a value, and any other strongly typed extended properties. The usual use of the timeseries data is in filling in mountain charts, which often require benchmark comparisons. It is a best practice to 'pre-munge' any benchmark or sector comparison series into the one timeseries object, as it means less work needs to be done in the browser to bring disparate data sets together.

Timeseries Delta

Timeseries delta behaves in the same manner as timeseries but treats the incoming timeseries date/values pairs as 'upsertable' values. This allows for existing timeseries to be updated without having to submit the entire date/value dataset.

Incoming date/value pairs will be matched on date. Matched pairs will have their value updated where new pairs will be inserted.

Timeseries delta can be loaded at either https://api.fundpress.io/dataloader/upserttimeseriesdelta or wss://api.fundpress.io/dataloader/upserttimeseriesdelta.

A typical timeseries delta object is shown below.

{
    "entityType": "CLSS",
    "clientCode": "LU123123123",
    "code": "quarterend_returns",
    "ccy": "N/A",
    "classification": "N/A",
    "periodicity": "QUARTERLY",
    "updateType": "REPLACE_MATCHING_DATE_RECORD",
    "values": [
    {
        "date": "1997-12-31",
        "value": 0.15,
        "benchmark_return": 42.2
    },
    {
        "date": "1997-12-31",
        "value": -0.0413,
        "benchmark_return": 42.2
    },
    {
        "date": "1998-03-31",
        "value": 0.0977,
        "benchmark_return": 42.2
    },

updateType can be set to either REPLACEMATCHINGDATERECORD or MERGEMATCHINGDATERECORD.

If the updateType is set to REPLACEMATCHINGDATE_RECORD matched values will be replaced and there is a potential for data loss.

For example: If there is an existing value of

{
    "date": "2019-01-01",
    "value": 1,
    "benchmark_value": 2
}

and there is an incoming value of

{
    "date": "2019-01-01",
    "value": 3
}

then the entire value will be replaced, and in this case the benchmark_value will be lost.

If the updateType is set to MERGEMATCHINGDATE_RECORD only supplied values will be set.

For example: If there is an existing value of

{
    "date": "2019-01-01",
    "value": 1,
    "benchmark_value": 2
}

and there is an incoming value of

{
    "date": "2019-01-01",
    "value": 3
}

then the value will be updated to 3 and the origin benchmark_value of 2 will remain unchanged.

The updateType field is required.

Fund Manager

Fund Managers are people that work on different fund products. They usually work on multiple products (requiring a one to many relationship) and often have bios and headshots. The fund manager service allows you to manage all of these facets.

Fund manager data can be loaded at either https://api.fundpress.io/dataloader/upsertFundmanager or wss://api.fundpress.io/dataloader/upsertFundmanager.

There is a filesize limit on the HTTPS endpoint when using application/json. If you need to load larger amounts of data, you will need to use multipart/form-data or the WSS endpoint

Parameter Value
HTTPS Endpoint https://api.fundpress.io/dataloader/upsertFundmanager
Headers X-KSYS-TOKEN
Content Type application/json or multipart/form-data
HTTP Method POST
Response Type application/json
Parameter Value
WSS Endpoint wss://api.fundpress.io/dataloader/upsertFundmanager
Headers X-KSYS-TOKEN
Content Type application/json
HTTP Method POST
Response Type application/json
{
    "code": "bob_carolgees",
    "name": "Bob Carolgees",
    "biography": [
        {
            "culture": "en-GB",
            "biography": "Bob worked in a cheese factory until he was seven, at which point he started managing money."
        },
        {
            "culture": "fr-FR",
            "biography": "Le Bob travail dans un fromagerie jusqu'à il avait sept années, quand il commencer a faire en sorte de l'argent."
        }
    ],
    "relatedEntities": ["LU123123123"],
    "headshot": "<Base64 Encoded Image>",
    "headshotContentType": "",
    "extended": {
        "years_of_service": 10
    }
}
Key Required Description
code TRUE The primary key of a fund manager is their code, which is a completely freeform string. It's use governs updates to this fund manager.
name TRUE The Fund Manager's name
biography FALSE The biography object allows you to provide the person's bio in multiple cultures.
relatedEntities FALSE The relatedEntities is an array of entity clientCodes already present in fundpress. If you don't provide a valid one, the insert will fail.
file FALSE A binary image. Only supported over HTTPS using a multipart/form-data form
headshot FALSE A base64 encoded image. Supported over HTTPS and WSS using application/json
headshotContentType FALSE The mime type of the base64 encoded image. Required when providing headshot
extended FALSE The extended properties are a freeform JSON object of your choosing and unlike in other data types, are not governed by any sort of property registration.

HTTPS vs Websocket Loading

All access to services is controlled by a token - meaning you need to be logged in to the system and pass in a token as a header or as a web socket initiation message. A token is obtained by calling the /login method of the auth service.

HTTPS methods use the X-KSYS-TOKEN header. However, the web sockets will require the token to be passed in an initiation handshake message like the one below.

{
    "token": "dac0b675-d627-4cc9-bbdd-6865700fa74b",
    "entityType": "CLSS",
    "totalRows": 30
}

Websocket methods allow for the bulk loading of many records at once, without the overhead of a single HTTPS connection per message. It is a preferable method to sending large JSON objects over an HTTP post as you can avoid timeouts. As websockets do not support headers, the init message is required.

For HTTPS requests, a simple post to one of the endpoints detailed below with a compliant message and a valid token will result in an insert or update of a particular resource (a fund, timeseries, etc…). With Websockets, the session need to be initiated by creating a web socket connection, sending the init message, then waiting for a response message containing the action

{
    "status": "GO"
}

When the go message is received the send should start issuing messages with compliant JSON bodies to the web socket endpoint. Note that the service will expect to receive a number of messages equal to the totalRows provided in the init message. When the total is received, processing will begin. When processing is finished, a message of the type below will be transmitted back to the caller of the web socket.

{ "status": "FINISHED", "failures": [] }

Note that the failures array will contain details of any errors encountered during the load. Any successes will be processed into the system, and the failures will need to be corrected and re-run. Fundpress services operate in an 'upsert' fashion. If you resend data it already has it will attempt to update the

Auditing

Each entity mentioned is audited in a backup table with an effectiveFrom and effectiveTo date. The effectiveFrom date is the date that the record was valid from, this will always have a value. The effectiveTo date can be null meaning it's the current valid record or have a date stating the last the record was relevant.

On initial insert of an entity a record will be entered into the backup table with the effectiveTo date set to null, showing that it's current. Therefor you can always assume that there will be at least one record in the backup table representing the entity. It's also possible to query just the backup table to get the entire data set, including current, even though this is not suggested.

On update for an entity a new record is entered in the backup table if there is a rowHash mismatch to the Entity table. In this case the effectiveTo date for the most recent backup record is set to the current time and a new record in the backup is entered representing the current update with the effectiveTo set to null.

Entity Entitlements

Users may be entitled in one of two ways:

  1. A user may be entitled directly to entity
  2. A user may be entitled to a list containing a collection of entities

Direct User to Entity Entitlement

Replace User Entity Entitlements

With this endpoint you are able to assign data entitlements of entities and/or lists to users. You need to either supply the dataEntitlements or dataEntitlementLists or both. Keep in mind that this will replace ALL existing dataEntitlements AND dataEntitlementLists that were previously assigned to the user. The data entitlement lists needs to already exist, this is simply assigning a existing list to a user.

Parameter Value
Endpoint https://api.fundpress.io/dataloader/replaceUserDataEntitlements
Headers X-KSYS-TOKEN
Content Type application/json
HTTP Method POST

Request

[
    {
        "userName": "bob.smith", // OR externalUserIdentifier
        "dataEntitlements": ["KYG772761147", "KS0943337096", "KS0281101625"],
        "dataEntitlementLists": ["institutional_UK", "institutional_US", "branch_london"]
    },
    {
        "userName": "lane.smith",
        "dataEntitlementLists": ["institutional_EU", "branch_poland"]
    }
]
Key Required Description
userName* FALSE The user's username you want to assign the entitlements
externalUserIdentifier* FALSE Alternative option to userName
dataEntitlements FALSE The entity clientCodes
dataEntitlementLists FALSE The data entitlement list names

Bulk Replace User Entity Entitlements

With this endpoint you are able to assign a set of data entitlements of entities, lists or both to the list of users provided. You need to either supply the dataEntitlements or dataEntitlementLists or both. Keep in mind that this will replace ALL existing dataEntitlements AND dataEntitlementLists that were previously assigned to the users. The data entitlement lists needs to already exists, this is simply assigning a existing list to a user.

Validation of the lists and users is done before the users are updated. If any of the validation fails then the process exits and no updates are done to any of the users. Only once all the validation passes are the users updated.

Parameter Value
Endpoint https://api.fundpress.io/dataloader/bulkReplaceUserDataEntitlements
Headers X-KSYS-TOKEN
Content Type application/json
HTTP Method POST
Response 200 - OK

Request

[
    {
        "userNames": ["bob.smith", "lane.smith", "pete.smith"], // OR externalUserIdentifier
        "dataEntitlements": ["KYG772761147", "KS0943337096", "KS0281101625"],
        "dataEntitlementLists": ["institutional_UK", "institutional_US", "branch_london"]
    }
]
Key Required Description
userNames* FALSE The user's username you want to assign the entitlements
externalUserIdentifiers* FALSE Alternative option to userName
dataEntitlements FALSE The entity clientCodes
dataEntitlementLists FALSE The data entitlement list names

Add User Entity Entitlements

With this endpoint you are able to assign a user data entitlement entities AND lists. You need to either supply the dataEntitlements OR dataEntitlementLists OR both. Keep in mind that this will not remove/replace existing dataEntitlements AND dataEntitlementLists that were previously assigned to the user, but simply adding to them. The data entitlement lists needs to already exists, this is simply assigning an existing list to a user.

Parameter Value
Endpoint https://api.fundpress.io/dataloader/addUserDataEntitlements
Headers X-KSYS-TOKEN
Content Type application/json
HTTP Method POST

Request

[
    {
        "userName": "jim.smith", // OR externalUserIdentifier
        "dataEntitlementLists": ["institutional_UK", "branch_london"],
        "dataEntitlements": ["AC12312399"]
    },
    {
        "userName": "lane.smith", // OR externalUserIdentifier
        "dataEntitlementLists": ["institutional_EU", "branch_poland"]
    }
]
Key Required Description
userName TRUE The user's username you want to assign the entitlements
externalUserIdentifier FALSE Alternative option to userName
dataEntitlements False The entity clientCodes
dataEntitlementLists FALSE The data entitlement list names

Bulk Add User Entity Entitlements

With this endpoint you are able to assign a set of data entitlements of entities, lists or both to the list of users provided. You need to either supply the dataEntitlements or dataEntitlementLists or both. Keep in mind that this will not remove or replace existing dataEntitlements AND dataEntitlementLists that were previously assigned to the users, but will simply add to them. The data entitlement lists needs to already exists, this is simply assigning a existing list to a user.

Validation of the lists and users is done before the users are updated. If any of the validation fails then the process exits and no updates are done to any of the users. Only once all the validation passes are the users updated.

Parameter Value
Endpoint https://api.fundpress.io/dataloader/bulkAddUserDataEntitlements
Headers X-KSYS-TOKEN
Content Type application/json
HTTP Method POST
Response 200 - OK

Request

[
    {
        "userNames": ["bob.smith", "lane.smith", "pete.smith"], // OR externalUserIdentifier
        "dataEntitlements": ["KYG772761147", "KS0943337096", "KS0281101625"],
        "dataEntitlementLists": ["institutional_UK", "institutional_US", "branch_london"]
    }
]
Key Required Description
userNames* FALSE The user's username you want to assign the entitlements
externalUserIdentifiers* FALSE Alternative option to userName
dataEntitlements FALSE The entity clientCodes
dataEntitlementLists FALSE The data entitlement list names

Remove User Entity Entitlements

With this endpoint you are able to remove an user's existing data entitlement entities AND lists. You need to either supply the dataEntitlements OR dataEntitlementLists OR both.

Parameter Value
Endpoint https://api.fundpress.io/dataloader/removeUserDataEntitlements
Headers X-KSYS-TOKEN
Content Type application/json
HTTP Method POST

Request

[
    {
        "userName": "jim.smith", // OR externalUserIdentifier
        "dataEntitlementLists": ["institutional_UK", "branch_london"],
        "dataEntitlements": ["AC12312399"]
    },
    {
        "userName": "lane.smith", // OR externalUserIdentifier
        "dataEntitlementLists": ["institutional_EU", "branch_poland"]
    }
]
Key Required Description
userName TRUE The user you want to target by username
externalUserIdentifier FALSE Alternative option to userName
dataEntitlements False The entity clientCodes
dataEntitlementLists FALSE The data entitlement list names

List User Entity Entitlements

This will simply list all the user's data entitlement lists and entities that are assigned to him.

Parameter Value
Endpoint https://api.fundpress.io/dataloader/listUserDataEntitlements
Headers X-KSYS-TOKEN
Content Type application/json
HTTP Method POST

Response

{
    "userName": "bob.smith" // OR externalUserIdentifier
}
Key Required Description
userName TRUE The user you want to target by username
externalUserIdentifier FALSE Alternative option to userName

Response

{
    "userName": "jim.smith",
    "dataEntitlementLists": [
        {
            "listName": "institutional_UK",
            "type": "CLSS",
            "entities": ["GB123123123", "GB12312314"]
        },
        {
            "listName": "branch_london",
            "type": "ACCT",
            "entities": ["AC123123123", "AC12312314"]
        }
    ],
    "dataEntitlements": [
        {
            "entityId": 1,
            "type": "ACCT",
            "clientCode": "AC123123123"
        },
        {
            "entityId": 2,
            "type": "FUND",
            "clientCode": "AC123453434"
        }
    ]
}

User to Entity List Entitlement

Entitlements Lists

Replace Entity Entitlement Lists

This endpoint will replace all the lists specified in the request. Existing records will be either overidden or removed.

Parameter Value
Endpoint https://api.fundpress.io/dataloader/replaceDataEntitlementLists
Headers X-KSYS-TOKEN
Content Type application/json
HTTP Method POST

Request

{
    "entitlementLists": [
        {
            "listName": "institutional_UK",
            "type": "CLSS",
            "entities": ["GB123123123", "GB12312314"]
        },
        {
            "listName": "institutional_EU",
            "type": "CLSS",
            "entities": ["GB123123123", "GB12312314"]
        }
    ]
}

Remove Entity Entitlement Lists

This endpoint will remove all the Entity Lists specified in the request.

Parameter Value
Endpoint https://api.fundpress.io/dataloader/removeDataEntitlementLists
Headers X-KSYS-TOKEN
Content Type application/json
HTTP Method POST

Request

{
    "listNames": ["institutional_UK", "institutional_USA"]
}

Entities within Entitlement Lists

Add Entity Entitlement List Entities

This endpoint will add entities to the specified lists

Parameter Value
Endpoint https://api.fundpress.io/dataloader/addDataEntitlementListEntities
Headers X-KSYS-TOKEN
Content Type application/json
HTTP Method POST

Request

{
    "entitlementLists": [
        {
            "listName": "institutional_UK",
            "type": "CLSS",
            "entities": ["GB123123123", "GB12312314"]
        },
        {
            "listName": "institutional_EU",
            "type": "CLSS",
            "entities": ["GB123123123", "GB12312314"]
        }
    ]
}

Remove Entity Entitlement List Entities

This endpoint will remove entities from the specified lists

Parameter Value
Endpoint https://api.fundpress.io/dataloader/removeDataEntitlementListEntities
Headers X-KSYS-TOKEN
Content Type application/json
HTTP Method POST

Request

{
    "entitlementLists": [
        {
            "listName": "institutional_UK",
            "entities": ["GB123123123", "GB12312314"]
        },
        {
            "listName": "institutional_EU",
            "entities": ["GB123123123", "GB12312314"]
        }
    ]
}

List Entity Entitlement Lists

This endpoint will return all available lists for the client that the user belongs to.

Parameter Value
Endpoint https://api.fundpress.io/dataloader/listDataEntitlementLists
Headers X-KSYS-TOKEN
Content Type application/json
HTTP Method POST

Response

{
    "entitlementLists": [
        {
            "listName": "institutional_UK",
            "type": "CLSS",
            "entities": ["GB123123123", "GB12312314"]
        },
        {
            "listName": "institutional_US",
            "type": "FUND",
            "entities": ["US123123123", "US12312314"]
        },
        {
            "listName": "branch_london",
            "type": "ACCT",
            "entities": ["AC123123123", "AC12312314"]
        }
    ]
}