Take a look under the hood of Codat Link.
At Codat, it’s vital that we make the process of connecting systems via our platform as easy and seamless as possible for small businesses. Link does just that. It’s a pre-built white-labeled interface that your business customers can use to connect their accounts seamlessly.
Since our inception five years ago, Codat has grown and evolved to support more platforms and different integration types. As a result, the requirements for Link have also naturally changed. This has led to several iterations of the product over the years.
🎬 How it all started
Our aim has always been to remain API-first. We believe that by prioritizing the capabilities and usability of our API, we will be able to provide other products built on top of our API faster and to a higher standard. However, not all of our clients can dedicate the resources to build on top of our API immediately and so we wanted to build a no-code link solution to help clients quickly integrate and use our product in their workflow.
The first version of Link delivered minimal functionality to get users linking as quickly as possible. The second version of Link was an attempt to build something better. To make it as usable as possible, it ran with no Javascript. However, it wasn’t very responsive and there weren’t many options to customize the branding, so version 3 was delivered. This iteration of Link was built inline on a razor view. It was a little more interactive and added more custom branding options. Version 4 of Link was a redesign for better UI and a new custom branding model built on .Net MVC.
✔️ Developing a unified journey
As Codat grew, we recognized the value of providing a platform for all small business data, so we added banking and commerce integrations to our product.
Unfortunately, updating Link to reflect this wasn’t such a straightforward task. We had to incorporate linking multiple platforms in a single flow, and we ended up surfacing separate flows linking to the different types of business data, resulting in a disjointed user journey. To solve this, we started a new project to rebuild our Link product and integrate the separate flows into a single, unified journey for users to link all of their business data.
The new white-labeled, no-code link solution was built entirely on top of our public API endpoints to demonstrate how a client could build their own link journey directly to our API. We developed the new solution using the latest technologies, including a .NET core backend, React frontend, and Azure services.
🔍 Stage one: analysis
The rebuild began with an analysis of Link’s existing functionality. Over the lifetime of Link, many features were built in to accommodate specific workflows that our clients wanted and to offer a high degree of customizability to the product. As part of the analysis, we had to decide which features still made sense and needed to be ported to the rebuild, which features needed to be improved, and which new functionality we wanted to introduce.
As we wanted the new Link product to remain highly customizable, the user flow could vary significantly based on a client’s configuration. For example, the client could determine what data types to integrate to, whether to allow retrying a link if there was an error, and where to redirect users at the end of the flow.
🗺️ Stage two: alignment
We mapped out multiple sequence diagrams and flows to understand the user journeys better, walking through each one with the Product, Delivery, and Engineering teams to ensure alignment and clarity. We then translated the diagrams into specifications, designs, and user stories for the Engineering team to build.
🔨 Stage three: build and refine
We started our first piece of development in November 2020. We wanted to build and release the newly redesigned product iteratively to get feedback quickly and adapt our design if needed. Therefore, we released the first iteration of the new Link product to support accounting integrations only, then added commerce integrations, and finally banking aggregators on top.
We followed a test-driven development (TDD) approach, building test scripts from the start to ensure a high-quality product and to minimize the number of bugs and disruptions to our clients migrating over to use the new Link.
🤔 The challenges
While redesigning the Link solution we encountered various challenges, a few of which are outlined below.
1. How do we ensure the solution is secure while allowing for a simple relinking journey?
Because Link users are our clients’ customers rather than our own, we do not have an easy way to authenticate the users going through the flow. This meant the link journey needed to be publicly accessible. In addition, we wanted to keep the relinking process as frictionless as possible for both our clients and the users.
Rather than implementing a one-time link solution, we have a static link endpoint that users can revisit to reauthenticate existing connections or link new platforms without any additional steps required from our client. To support this on a publicly accessible endpoint, we have to ensure any information we surface to help users through the relinking process does not come at the risk of revealing any personal information. Every piece of information that is exposed through Link is carefully considered in terms of the benefit it provides to the usability of the solution versus the risk it brings as an avenue of attack.
At times, we had to change requirements to address this. For example, an initial requirement for the rebuild was to show users what platforms had already been connected to avoid duplicate links in our system. However, understanding the platforms a company uses adds risk to allow a malicious user to impersonate the company, so instead, we show the number of linked connections but not details on which platforms are connected. By building directly to our API in an authorized link flow, this security limitation can be overcome.
2. How do we release changes and migrate users to the redesigned solution?
Our previous Link solution was already actively being used by our clients and their business customers. It was vital we developed the new solution in a non-breaking way to reduce the impact on existing clients. To achieve this, we implemented the new solution behind a feature toggle and exposed this toggle to clients so they could control when they were ready to move to the new solution. For all new clients, we automatically enabled the new link flow to avoid them building to a deprecated application.
To reduce the overhead for clients to move to the new link flow, we migrated their existing link customization settings to the new link site and made sure to keep their old settings inline with the new so when they chose to switch over to the new link site they wouldn’t need to reconfigure their customization. For any new features we added to the rebuild, we also made sure to feature toggle off for them by default to maintain the same behavior between the old and new flows. Where we changed the structure of API endpoints, we made sure to include redirects from the old to the new URLs to ensure clients wouldn’t need to make any code changes when switching to the new flow.
3. How do we prevent duplicate links to a platform without displaying what has already been linked?
Due to the security limitations outlined above, there is no way for a client to understand which platforms have already been linked when revisiting the link flow. This became more of a problem for the newly redesigned flow which included commerce and banking connections as users are more likely to have multiple commerce integrations and banks to link.
When a user links the same platform again, this creates duplicate data against the company in the Codat system and puts the onus on our clients to detect. The link site rebuild highlighted the need for us to be able to recognize and prevent duplicate connections after a successful link to keep the linked data management easy for our clients. This is still a work in progress but proved the benefit of us building on top of our own APIs to show where we could make improvements to our API.
🚀 Results
The first iteration of the redesigned link site supporting accounting and commerce integrations was made available in March 2021. Support for linking banking integrations via TrueLayer and Plaid was added in April 2021, and the deprecation of the old link site was announced at the end of the same month. Our Solutions and Support teams helped clients through the process of moving to the new link solution and by August 2021, the old link site was deprecated.
We now have a single unified link solution for users to link multiple platforms in a single flow. Our white-labeled solution is mobile responsive and allows clients to customize the flow to align with their branding and specific use case. The new solution was designed to be easily extensible to react to and deliver client requirements at short notice.
Since the new Link solution went live, we have been able to prove this out with new client feature requests and product improvements. Most recently, we’ve added support to allow users to manually upload files as part of the link flow. The white-labeled link solution now supports a significant number of links per day.
Amy Chu, Senior Software Engineer
You can start building with Codat for free today. Sign up here for a free account or visit our docs to find out more.