Overview
The Dynamic Planner software suite contains a wide range of functionality to support the provision of compliant advice to a customer. From capturing information supplied by the customer, through analysis of the customer’s current situation, forecasting future positions, generating reports to executing transactions.
Users access the functionality of the Dynamic Planner through a web application. The same data and functionality is also exposed through a set of web services, collectively called Open Dynamic Planner. This allows custom applications to be developed by third parties to take advantage of Dynamic Planner's functionality in new and novel ways.
Coverage
The Open API will continue to evolve according to demand. Currently it supports the following areas of functionality:
| Endpoint | Description |
|---|---|
| CRM | The Customer Relationship Management endpoint allows for the creation, retrieval and updating of an advice firm's clients. This includes personal information (such as name, contact details and date of birth) as well as relationship information (e.g. which other clients is the client associated with, who is their adviser and which organisation are they serviced by). |
| Publish Subscribe | This endpoint allows a client application to subscribe for notifications of events happening within Dynamic Planner. For example, a client application can subscribe to the "Client Document Created" event, providing a call back URL, so it is called each time the event is published by Dynamic Planner. |
| Finances | Documentation will be completed soon! |
REST Based
The Open Dynamic Planner APIs are REST based. Our API has resource-oriented URLs, accepts JSON-encoded bodies, returns JSON-encoded responses, and uses standard HTTP response codes, authentication, and verbs.
The HTTP Verbs generally supported within the API are:
| HTTP Verb | Description |
|---|---|
| GET | The GET method requests a representation of the specified resource. Requests using GET will only retrieve data so are safe and idempotent. |
| POST | The POST method submits a representation of an entity to the specified resource, creating a new child resource. Each POST will result in a new child resource which means a retry may result in a second resource being created (i.e. POST is neither safe nor idempotent). For this reason it is generally avoided. |
| PUT | The PUT method submits a representation of the specified resource. If the resource does not already exist, it will be created. If the resource already exists, it will be updated. This means that a PUT can be safely retried. PUT is considered idempotent. |
| DELETE | The DELETE method deletes the specified resource. If the resource exists, it will be deleted. If the resource does not exist (i.e. it has already been deleted) there will be no impact. This means that a DELETE can be safely retried. DELETE is considered idempotent. |
Being pragmatic, and following feedback, we have moved away from a truly RESTful implementation. The areas that might be considered a deviation from a RESTful implementation are:
- Resources are not discoverable within the API responses. Instead the supported resources (and their URIs) are pre-defined in the Swagger Files.
- Use of the PUT method against an existing resource will merge the supplied representation with the existing resource rather than replacing it. This means any sub-part of the existing resource that is not overridden will stay the same rather than being removed.