The client address API at /v2/clients/{clientId}/addresses is being extended by adding property details to the address resource. This post serves as notice to our developer community of this change, and while this is considered to be a minor update, it highlights some potential pitfalls that need to be avoided when we release this into production. We'll discuss these below when we talk about the operations for managing them, but first things first - what do we mean by property details?
List of recent updates and fixes for our public APIs
Read More
- Fixed bug that caused a 500 internal error when requesting a manual fund via funds API
- Property "isVisibleToClient" has been added to new Plan API
- Fixed a bug that made it impossible to add dependant while using Tenant Client Credential (TCC) flow
- A 500 internal server error was returned When a 3rd party app tried to POST a dependant through the API using tenant client credentials flow.
- Posting a relationship with type 'Employee,Employer' creates the relationship the other way around e.g. corporate client is 'Employee' and personal client is 'Employer'.
- Fixed an issue that gave a "403 Forbidden" on using PUT against any plan using new Plan API.
Plans are a foundational resource in our public API and apart from Clients, probably the most important to our customers. Plans, as a concept, model the many varied financial products available in the market, both advised and non-advised, so in addition to being central to what our customers do, they are also fairly complex as a result.
We released our first version of the iO Store in February this year and have had good adoption and loads of interest from the community. One of the key features we made available as part of the App development tools, is the ability to cryptographically sign Links and Forms using a canonical algorithm that we documented here.
The platform team have been working hard, releasing new APIs and fixes, quite steadily over the last few months and this will continue throughout this year and beyond. If you are on our mailing list then you may already be aware of the work that has been going on and that we recently announced the release of our new Document API for general availability. We are excited about this new Document API because we believe we have provided a simpler and more efficient way for customers to upload and download documents and have aligned these APIs with our flexible object storage architecture. Read on to find out more about the design and architecture or if you just want to know how to use them skip to How to use the APIs.
We have been in a "beta" phase with our APIs now for around 3 months in which time we have had overwhelming interest and engagement from customers and partners. The purpose of the beta phase was to give interested parties early access to our APIs so that we could not only gauge the interest, but also get some useful feedback on usability and anything improvements. We have had a huge amount of great feedback so we would like to thank those that have been involved for doing so.
The feedback we have had, has been largely in three main areas:
Read More
The feedback we have had, has been largely in three main areas:
- Comprehension - Some APIs were hard to understand or had references to properties that were foreign or confusing
- API Gaps - There were some gaps that prevented common use cases from being realised
- Granularity - Some APIs were too granular and resulted in some use cases being quite chatty
To address these and other issues we have recently made some significant changes to our APIs. The APIs released to "beta" are APIs that we have been using internally for sometime now and will continue to use for awhile more. In order to address some of the feedback and improve our customers experience we have decided to release a set of version 2 endpoints "v2". This means we are not changing or extending any of our existing v1 APIs but producing new improved versions.
