Whether you are a SaaS founder/ BD/ CX/ tech person, you know how crucial data safety is to close important deals. If your customer senses even the slightest risk to their internal data, it could be the end of all potential or existing collaboration with you.
But ensuring complete data safety — especially when you need to integrate with multiple 3rd party applications to ensure smooth functionality of your product — can be really challenging.
While a unified API makes it easier to build integrations faster, not all unified APIs work the same way.
In this article, we will explore different data sync strategies adopted by different unified APIs with the examples of Finch API and Knit — their mechanisms, differences and what you should go for if you are looking for a unified API solution.
Let’s dive deeper.
But before that, let us first revisit the primary components of a unified API and how exactly they make building integration easier.
How does a unified API work?
As we have mentioned in our detailed guide on Unified APIs,
“A unified API aggregates several APIs within a specific category of software into a single API and normalizes data exchange. Unified APIs add an additional abstraction layer to ensure that all data models are normalized into a common data model of the unified API which has several direct benefits to your bottom line”.
The mechanism of a unified API can be broken down into 4 primary elements —
- Authentication and authorization
- Connectors (1:Many)
- Data syncs
- Ongoing integration management
1.Authentication and authorization
Every unified API — whether its Finch API, Merge API or Knit API — follows certain protocols (such as OAuth) to guide your end users authenticate and authorize access to the 3rd party apps they already use to your SaaS application.
2. Connectors
Not all apps within a single category of software applications have the same data models. As a result, SaaS developers often spend a great deal of time and effort into understanding and building upon each specific data model.
A unified API standardizes all these different data models into a single common data model (also called a 1:many connector) so SaaS developers only need to understand the nuances of one connector provided by the unified API and integrate with multiple third party applications in half the time.
3. Data Sync
The primary aim of all integration is to ensure smooth and consistent data flow — from the source (3rd party app) to your app and back — at all moments.
We will discuss different data sync models adopted by Finch API and Knit API in the next section.
4. Ongoing integration Management
Every SaaS company knows that maintaining existing integrations takes more time and engineering bandwidth than the monumental task of building integrations itself. Which is why most SaaS companies today are looking for unified API solutions with an integration management dashboards — a central place with the health of all live integrations, any issues thereon and possible resolution with RCA. This enables the customer success teams to fix any integration issues then and there without the aid of engineering team.
.png)
How data sync happens in Unified APIs?
For any unified API, data sync is a two-fold process —
- Data sync between the source (3rd party app) and the unified API provider
- Data sync between the unified API and your app
.png)
Between the third party app and unified API
First of all, to make any data exchange happen, the unified API needs to read data from the source app (in this case the 3rd party app your customer already uses).
However, this initial data syncing also involves two specific steps — initial data sync and subsequent delta syncs.
Initial data sync between source app and unified API
Initial data sync is what happens when your customer authenticates and authorizes the unified API platform (let’s say Finch API in this case) to access their data from the third party app while onboarding Finch.
Now, upon getting the initial access, for ease of use, Finch API copies and stores this data in their server. Most unified APIs out there use this process of copying and storing customer data from the source app into their own databases to be able to run the integrations smoothly.
While this is the common practice for even the top unified APIs out there, this practice poses multiple challenges to customer data safety (we’ll discuss this later in this article). Before that, let’s have a look at delta syncs.
What are delta syncs?
Delta syncs, as the name suggests, includes every data sync that happens post initial sync as a result of changes in customer data in the source app.
For example, if a customer of Finch API is using a payroll app, every time a payroll data changes — such as changes in salary, new investment, additional deductions etc — delta syncs inform Finch API of the specific change in the source app.
There are two ways to handle delta syncs — webhooks and polling.
In both the cases, Finch API serves via its stored copy of data (explained below)
In the case of webhooks, the source app sends all delta event information directly to Finch API as and when it happens. As a result of that “change notification” via the webhook, Finch changes its copy of stored data to reflect the new information it received.
Now, if the third party app does not support webhooks, Finch API needs to set regular intervals during which it polls the entire data of the source application to create a fresh copy. Thus, making sure any changes made to the data since the last polling is reflected in its database. Polling frequency can be every 24 hours or less.
This data storage model could pose several challenges for your sales and CS team where customers are worried about how the data is being handled (which in some cases is stored in a server outside of customer geography). Convincing them otherwise is not so easy. Moreover, this friction could result in additional paperwork delaying the time to close a deal.
Data syncs between unified API and your app
The next step in data sync strategy is to use the user data sourced from the third party app to run your business logic. The two most popular approaches for syncing data between unified API and SaaS app are — pull vs push.
What is Pull architecture?
.png)
Pull model is a request-driven architecture: where the client sends the data request and then the server sends the data. If your unified API is using a pull-based approach, you need to make API calls to the data providers using a polling infrastructure. For a limited number of data, a classic pull approach still works. But maintaining polling infra and/making regular API calls for large amounts of data is almost impossible.
What is Push architecture?
On the contrary, the push model works primarily via webhooks — where you subscribe to certain events by registering a webhook i.e. a destination URL where data is to be sent. If and when the event takes place, it informs you with relevant payload. In the case of push architecture, no polling infrastructure is to be maintained at your end.
How does Finch API send you data?
There are 3 ways Finch API can interact with your SaaS application.
- First, for each connected user, you are required to maintain a polling infrastructure at your end and periodically poll the Finch copy of the customer data. This approach only works when you have a limited number of connected users.
- You can write your own sync functions for more frequency data syncs or for specific data syncing needs at your end. This ad-hoc sync is easier than regular polling, but this method still requires you to maintain polling infrastructure at your end for each connected customer.
- Finch API also uses webhooks to send data to your SaaS app. Based on your preference, it can either send you notification via webhooks to start polling at your end, or it can send you appropriate payload whenever an event happens.
How does Knit API send data?
Knit is the only unified API that does NOT store any customer data at our end.
Yes, you read that right.
In our previous HR tech venture, we faced customer dissatisfaction over data storage model (discussed above) firsthand. So, when we set out to build Knit Unified API, we knew that we must find a way so SaaS businesses will no longer need to convince their customers of security. The unified API architecture will speak for itself. We built a 100% events-driven webhook architecture. We deliver both the initial and delta syncs to your application via webhooks and events only.
The benefits of a completely event-driven webhook architecture for you is threefold —
- It saves you hours of engineering resources that you otherwise would spend in building, maintaining and executing on polling infrastructure.
- It ensures on-time data regardless of the payload. So, you can scale as you wish.
- It supports real time use cases which a polling-based architecture doesn’t support.
Finch API vs Knit API
Let’s look at the other components of the unified API (discussed above) and what Knit API and Finch API offers.
1. Authorization & authentication
Knit’s auth component offers a Javascript SDK which is highly flexible and has a wider range of use cases than Reach/iFrame used by the Finch API for front-end. This in turn offers you more customization capability on the auth component that your customers interact with while using Knit API.
2. Ongoing integration Management
The Knit API integration dashboard doesn’t only provide RCA and resolution, we go the extra mile and proactively identify and fix any integration issues before your customers raises a request.
Knit provides deep RCA and resolution including ability to identify which records were synced, ability to rerun syncs etc. It also proactively identifies and fixes any integration issues itself.
In comparison, the Finch API customer dashboard doesn’t offer as much deeper analysis, requiring more work at your end.
Final thoughts
Wrapping up, Knit API is the only unified API that does not store customer data at our end, and offers a scalable, secure, event-driven push data sync architecture for smaller as well as larger data loads.
By now, if you are convinced that Knit API is worth giving a try, please click here to get your API keys. Or if you want to learn more, see our docs
