Welcome to DFS API

The DFS API catalog gives interested parties such as implementation partners, an insight into our API offering so that you can design and develop solutions based on APIs with focus on the functionalities required to build Hybrid Wealth Management solutions. The target audience is primarily software engineers and business analysts with knowhow in the finance industry and specifically the wealth domain.

This portal will continuously grow to be the main resource for docs, guides, cookbooks and examples for additiv’s DFS API products and services.

The DFS APIs are the backbone of the solution and are used by additiv's built DFS standard B2B and B2C web applications. Specifically, the Wealth APIs are the backbone of additiv’s Hybrid Wealth Management offering.

Introduction

DFS services expose a RESTful API that aims to speaks the business domain language while hiding the business logic complexity from the consuming systems.

Multiple API hosts

DFS exposes multiple API groups, each serving different purposes. Different API groups might be under different hosts and a single group might be served by 1-n hosts.

API Gateway

In a microservices architecture, the client apps usually need to consume functionality from more than one microservice / host. If that consumption is performed directly, the client needs to handle multiple calls to microservice endpoints. (source: The API gateway pattern versus the Direct client-to-microservice communication)

DFS APIs continuously evolve and new microservices / hosts are introduced or existing microservices are updated. This, among many other reasons is why live APIs are accessed by client apps via an API gateway.

For simplicity, this portal shows the endpoints in the standalone form and not under the API gateway.

Getting Started

All consumers using the DFS APIs (e.g. client applications, postman users etc.), must be uniquely identified and authorized to access DFS endpoints regardless if there is an authenticated person.

  • Each consumer might be authorized to a specific sub set of endpoints based on the app needs and usage.

This is achieved by a set of credentials provided to every consumer of the APIs

  • AppId (i.e. username of the app)
  • APIKey (i.e. secret / password of the app to match the AppId)

Since DFS APIs are designed for multi tenancy, these credentials also allow the system to identify the tenant which the consumer is requesting to access. A single set of credentials authorizes a consumer to a single tenant.

Endpoints that require such authorization (the vast majority) require an Authorization header (The BasicAuth token) in every call.

  • The AppId and ApiKey must be sent on the Authorization header of the request encoded as Base64: Base64(AppId:APIKey).
  • For example appId="xx9idmi1awVVAmJvCJxO3zURBx25K0" and apiKey="maKQgiYl7HjbUmRubHIFJ3dOnQTFys"
  • Encoding in base 64 of this string "xx9idmi1awVVAmJvCJxO3zURBx25K0:maKQgiYl7HjbUmRubHIFJ3dOnQTFys" results in this string "eHg5aWRtaTFhd1ZWQW1KdkNKeE8zelVSQngyNUswOm1hS1FnaVlsN0hqYlVtUnViSElGSjNkT25RVEZ5cw=="
  • Adding the "Basic " prefix will give you the required authorization header value "Basic eHg5aWRtaTFhd1ZWQW1KdkNKeE8zelVSQngyNUswOm1hS1FnaVlsN0hqYlVtUnViSElGSjNkT25RVEZ5cw=="
  • These credentials and specifically the ApiKey must be treated as secret and stored in a secure location.

Client Applications Access to APIs

Client apps are a common type of consumers of the DFS API and should follow some basic patterns.

  • Access the APIs via the API gateway and not the API hosts directly.
  • Do not store the API access credentials client side or in source code of the app even if they are obfuscated
  • For standard web applications, such values should be stored in an app middleware on the server side which will also remove the need to do encoding client side.

Playing with the APIs

The API portal does not offer, at this point, ability to get access keys and execute calls against the end points. To get access to a running system with live APIs, please first contact us with your specific needs

Not a developer?

Contact us to schedule a demo of our standard Hybrid Wealth apps to learn what can be achieved with these APIs and how additiv can solve your business needs.

The endpoints provided in this portal are not a guarantee of service. Partners authorized to access a live system will get regular updates which includes new and updated APIs. This portal is updated regularly but less frequently.

License & Terms of Use

The additiv DFS API catalog can only be used by additiv’s internal engineering teams or by licensed parties under a license agreement containing restrictions on use and disclosure. The DFS software and documentation, including the APIs, are protected by intellectual property laws. additiv’s objective is to focus on developing robust APIs as it designs and further develops the available services. The APIs may change in the course of architectural improvements, addition of capabilities, and optimization of performance. The API endpoints provided in this portal are not a guarantee of service. Parties authorized to access a live system will get regular updates which includes new, deprecated and updated APIs and in some cases, APIs might also be removed. Except as expressly permitted in individual license agreements or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish or display any part of the content on this site / document, in any form, or by any means.


Last update: DFS version 2020.2 CTP W21

Passionate about creating beautiful software that change the future of Banking? Join additiv’s engineering teams.

Copyright © 2020 additiv AG and/or its affiliates. All rights reserved.