Welcome to the DFS API

DFS services expose a RESTful API that aims to speak 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 may reside under different hosts while a single group may serve 1-n hosts.

API Gateway

In a microservices architecture, 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.

API Domains

core: Admin
Clients
Communication
Contact Identity
Contact Relationship
Dms
ECS
Email Bridge
Notification
OTP
Reporting
Resource
Ticketing
credit: Collateral
Common
Document
Facility
Fee
Instance
Product
Risk
Dynamic Schema
Lender
Repayment
insurance: Product Config
orchestration: Workflow
wealth: Alerting
Fees
Funding
MIS
Securities
Target Market
Task Automation
Wealth

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 access a specific sub-set of endpoints based on the app needs and usage.

This is achieved via a set of credentials provided to every consumer of the APIs (referred to as Client App) which identifies the App and allows the system to determine the scope(s) and access policy group(s) assigned to it.

Client ID (i.e. username of the app)
Client Secret (i.e. password of the app to match the Client ID)

Since DFS APIs are designed for multi tenancy, these credentials also allow the system to identify the tenant(s) which the App is authorized to access.

All endpoints that require such authorization (the vast majority) are protected with a Bearer Authorization token (JWT) and require the caller to pass the string Bearer {JwtAccessToken} in the Authorization header.

Obtaining Access Token

A client application can easily obtain the needed token by issuing a request to the connect/token endpoint of DFS identity server with valid app credentials, the required scope, grant_type etc. Depending on the requirements and permissions, different token types can be requested (e.g User token, App token). For example:
{ scope: "DfsApi", grant_type: "client_credentials", client_id: "v072tGsxjdsaTuZlzil7TnDUAqr5d3", client_secret: "XMevpAsNKckL7Z3veXkayxgaleQLEp", tenant_uid: "X101XX1X-0X1X-1X0X-X0XX-X10X10X101XX" }

Not a developer?

Contact us to schedule a demo of our 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.