HRIS or Human Resources Information Systems have become commonplace for organizations to simplify the way they manage and use employee information. For most organizations, information stored and updated in the HRIS becomes the backbone for provisioning other applications and systems in use. HRIS enables companies to seamlessly onboard employees, set them up for success and even manage their payroll and other functions to create an exemplary employee experience.

However, integration of HRIS APIs with other applications under use is essential to facilitate workflow automation. Essentially, HRIS API integration can help businesses connect diverse applications with the HRIS to ensure seamless flow of information between the connected applications. HRIS API integrations can either be internal or customer-facing. In internal HRIS integrations, businesses connect their HRIS with other applications they use, like ATS, Payroll, etc. to automate the flow of information between the same. On the other hand, with customer-facing HRIS integrations, businesses can connect their application or product with the end customer’s HR applications for data exchange. 

This article seeks to serve as a comprehensive repository on HRIS API integration, covering the benefits, best practices, challenges and how to address them, use cases, data models, troubleshooting and security risks, among others. 

Benefits of HRIS API integration

Here are some of the top reasons why businesses need HRIS API integration, highlighting the benefits they bring along:

• Higher employee productivity: HRIS API integration ensures that all data exchange between HRIS and other applications is automated and doesn’t require any human intervention. This considerably reduces the time and effort spent on manually updating all platforms with HR related data. This ensures that employees are able to focus more on value add tasks, leading to increased productivity and an improved employee experience.

• Reduced errors: Manual data entry is prone to errors. For instance, if during payroll updation, the compensation of an employee is entered incorrectly and differently from HRIS data, the employee will receive incorrect compensation, leading to regulatory/ financial discrepancies and employee displeasure. 

• End customer satisfaction: This is specifically for customer-facing HRIS integrations. By facilitating integration with your end customer’s HRIS applications and your product, you can foster automated data sync between the applications, eliminating the need for the customer to manually give you access to the data needed. This considerably augments customer experience and satisfaction.

• Expanded customer base: The ability to offer integrations with associated applications like payroll, attendance, etc. is something that most HR professionals seek. Therefore, when an application offers integrations with a wide range of HRIS, the total addressable market or TAM, significantly increases, augmenting the overall reach and potential customers. 

HRIS API Data Models Explained

The different HRIS tools you use are bound to come with different data models or fields which will capture data for exchange between applications. It is important for HR professionals and those building and managing these integrations to understand these data models, especially to ensure normalization and transformation of data when it moves from one application to another. 

Employees/ Employee Profiles

This includes details of all employees whether full time or contractual, including first and last name, contact details, date of birth, email ID, etc. At the same time, it covers other details on demographics and employment history including status, start date, marital status, gender, etc. In case of a former employee, this field also captures termination date. 

Employee Contact Details

This includes personal details of the employee, including personal phone number, address, etc. which can be used to contact employees beyond work contact information. 

Employee Profile Picture

Employee profile picture object or data model captures the profile picture of the employees that can be used across employee records and purposes. 

Employment Type

The next data model in discussion focuses on the type or the nature of employment. An organization can hire full time employees, contractual workers, gig workers, volunteers, etc. This distinction in employment type helps differentiate between payroll specifications, taxation rules, benefits, etc. 

Location

Location object or data model refers to the geographical area for the employee. Here, both the work location as well as the residential or native/ home location of the employee is captured. This field captures address, country, zip code, etc. 

Leave Request

Leave request data model focuses on capturing all the time off or leave of absence entries made by the employee. It includes detailing the nature of leave, time period, status, reason, etc.

Leave Balance

Each employee, based on their nature of employment, is entitled to certain time off in a year. The leave balance object helps organizations keep a track of the remaining balance of leave of absence left with the employee. With this, organizations can ensure accurate payroll, benefits and compensation. 

Attendance 

This data model captures the attendance of employees, including fields like time in, time out, number of working hours, shift timing, status, break time, etc. 

Organizational Structure

Each organization has a hierarchical structure or layers which depict an employee’s position in the whole scheme of things. The organizational structure object helps understand an employee’s designation, department, manager (s), direct reportees, etc. 

Bank Details

This data model focuses on capturing the bank details of the employee, along with other financial details like a linked account for transfer of salary and other benefits that the employee is entitled to. In addition, it captures routing information like Swift Code, IFSC Code, Branch Code, etc. 

Dependents

Dependents object focuses on the family members of an employee or individuals who the employee has confirmed as dependents for purposes of insurance, family details, etc. This also includes details of employees’ dependents including their date of birth, relation to the employee, among others. 

KYC

This includes the background verification and other details about an employee with some identification proof and KYC (know your customer) documents. This is essential for companies to ensure their employees are well meaning citizens of the country meeting all compliances to work in that location. It captures details like Aadhar Number, PAN Number or unique identification number for the KYC document. 

Compensation

This data model captures all details related to compensation for an employee, including total compensation/ cost to company, compensation split, salary in hand, etc. It also includes details on fixed compensation, variable pay as well as stock options. Compensation object also captures the frequency of salary payment, pay period, etc. 

HRIS API Integration Best Practices for Developers

To help you leverage the benefits of HRIS API integrations, here are a few best practices that developers and teams that are managing integrations can adopt:

Prioritize which HRIS integrations are needed for efficient resource allocation

This is extremely important if you are building integrations in-house or wish to connect with HRIS APIs in a 1:1 model. Building each HRIS integration or connecting with each HR application in-house can take four weeks on an average, with an associated cost of ~$10K. Therefore, it is essential to prioritize which HRIS integrations are pivotal for the short term versus which ones can be pushed to a later period. If developers focus all their energy in building all HRIS integrations at once, it may lead to delays in other product features. 

Understand the HRIS API before integrating with it

Developers should spend sufficient time in researching and understanding each individual HRIS API they are integrating with, especially in a 1:1 case. For instance, REST vs SOAP APIs have different protocols and thus, must be navigated in different ways. Similarly, the API data model, URL and the way the HRIS API receives and sends data will be distinct across each application. Developers must understand the different URLs and API endpoints for staging and live environments, identify how the HRIS API reports errors and how to respond to them, the supported data formats (JSON/ XML), etc.  

Stay up to date with API versioning

As HRIS vendors add new features, functionalities and update the applications, the APIs keep changing. Thus, as a best practice, developers must support API versioning to ensure that any changes can be updated without impacting the integration workflow and compatibility. To ensure conducive API versioning, developers must regularly update to the latest version of the API to prevent any disruption when the old version is removed. Furthermore, developers should eliminate the reliance on or usage of deprecated features, endpoints or parameters and facilitate the use of fallbacks or system alter notifications for unprecedented changes. 

Set appropriate rate limits and review them regularly

When building and managing integrations in-house, developers must be conscious and cautious about rate limiting. Overstepping the rate limit can prevent API access, leading to integration workflow disruption. To facilitate this, developers should collaboratively work with the API provider to set realistic rate limits based on the actual usage. At the same time, it is important to constantly review rate limits against the usage and preemptively upgrade the same in case of anticipated exhaustion. Also, developers should consider scenarios and brainstorm with those who use the integration processes the maximum to identify ways to optimize API usage.

Document HR integration process for each HRIS

Documenting the integration process for each HRIS is extremely important. It ensures there is a clear record of everything about that integration in case a developer leaves the organization, fostering integration continuity and seamless error handling. Furthermore, it enhances the long-term maintainability of the HRIS API integration. A comprehensive document generally captures the needs and objectives of the integration, authentication methods, rate limits, API types and protocols, testing environments, safety net in case the API is discontinued, common troubleshooting errors and handling procedures, etc. At the same time this documentation should be stored in a centralized repository which is easily accessible. 

Test HRIS integrations across different scenarios

HRIS integration is only complete once it is tested across different settings and they continue to deliver consistent performance. Testing is also an ongoing process, because everytime there is an update in the API of the third-party application, testing is needed, and so is the case whenever there is an update in one’s own application. To facilitate robust testing, automation is the key. Additionally, developers can set up test pipelines and focus on monitoring and logging of issues. It is also important to check for backward compatibility, evaluate error handling implementation and boundary values and keep the tests updated. 

Guides to popular HRIS APIs

Each HRIS API in the market will have distinct documentation highlighting its endpoints, authentication methods, etc. To make HRIS API integration for developers simpler, we have created a repository of different HR application directories, detailing how to navigate integrations with them:

• Workday API Integration Guide
• ADP API Integration Guide
• greytHR API Guide
• Zoho People API Guide
• Ceridian Dayforce API Directory
• Oracle HCM API Directory
• Gusto API Directory
• Zenefits API Directory
• Freshteam API Directory
• Keka API Directory
• Greenhouse API Directory
• Darwinbox API Directory
• SuccessFactors API Directory
• Namely API Directory

Common HRIS API Integration Challenges 

While there are several benefits of HRIS API integration, the process is fraught with obstacles and challenges, including:

Diversity of HRIS API providers

Today, there are 1000s of HR applications in the market which organizations use. This leads to a huge diversity of HRIS API providers. Within the HRIS category, the API endpoints, type of API (REST vs SOAP), data models, syntax, authentication measures and standards, etc. can vary significantly. This poses a significant challenge for developers who have to individually study and understand each HRIS API before integration. At the same time, the diversity also contributes to making the integration process time consuming and resource intensive.

Lack of public APIs and robust documentation

The next challenge comes from the fact that not all HRIS APIs are publicly available. This means that these gated APIs require organizations to get into partnership agreements with them in order to access API key, documentation and other resources. Furthermore, the process of partnering is not always straightforward either. It ranges from background and security checks to lengthy negotiations, and at times come at a premium cost associated. At the same time, even when APIs are public, their documentation is often poor, incomplete and difficult to understand, adding another layer of complexity to building and maintaining HRIS API integrations. 

Difficulty in testing across environments

As mentioned in one of the sections above, testing is an integral part of HRIS API integration. However, it poses a significant challenge for many developers. On the one hand, not every API provider offers testing environments to build against, pushing developers to use real customer data. On the other hand, even if the testing environment is available, running integrations against the same, requires thorough understanding and a steep learning curve for SaaS product developers. Overall, testing becomes a major roadblock, slowing down the process of building and maintaining integrations. 

Maintaining data quality and standardization

When it comes to HRIS API integration, there are several data related challenges that developers face across the way. To begin with, different HR providers are likely to share the same information in different formats, fields and names. Furthermore, data may also not come in a simple format, forcing developers to collect and calculate the data to decipher some values out of it. Data quality adds another layer of challenges. SInce standardizing and transforming data into a unified format is difficult, ensuring its accuracy, timeliness, and consistency is a big obstacle for developers.  

Scaling HRIS integrations

Scaling HRIS API integrations can be a daunting task, especially when integrations have to be built 1:1, in-house. Since building each integration requires developers to understand the API documentation, decipher data complexities, create custom codes and manage authentication, the process is difficult to scale. While building a couple of integrations for internal use might be feasible, scaling customer-facing integrations leads to a high level of inefficient resource use and developer fatigue. 

Post integration maintenance

Keeping up with third-party APIs and integration maintenance is another challenge that developers face. To begin with as the API versions update and change, HRIS API integration must reflect those changes to ensure usability and compatibility. However API documentation seldom reflects these changes, making it a cumbersome task for developers to keep pace with the changes. And, the inability to update API versioning can lead to broken integrations, endpoints and consistency issues. Furthermore, monitoring and logging, necessary to monitor the health of integrations can be a big challenge, with an additional resource allocation towards checking logs and addressing errors promptly. Managing rate limiting and throttling are some of the other post integration maintenance challenges that developers tend to face. 

Building Your First HRIS Integration with Knit: Step-by-Step Guide

Building Your First E-Signature Integration with Knit

Knit provides a unified HRIS API that streamlines the integration of HRIS solutions. Instead of connecting directly with multiple HRIS APIs, Knit allows you to connect with top providers like Workday, Successfactors, BambooHr, and many others through a single integration.

Learn more about the benefits of using a unified API.

Getting started with Knit is simple. In just 5 steps, you can embed multiple HRIS integrations into your APP.

Steps Overview:

1. Create a Knit Account: Sign up for Knit to get started with their unified API. You will be taken through a getting started flow.
2. Select Category: Select HRIS from the list of available option on the Knit dashboard
3. Register Webhook: Since one of the use cases of HRIS integrations is to sync data at frequent intervals, Knit supports scheduled data syncs for this category. Knit operates on a push based sync model, i.e. it reads data from the source system and pushes it to you over a webhook, so you don’t have to maintain a polling infrastructure at your end. In this step, Knit expects you to tell us the webhook over which it needs to push the source data.
4. Set up Knit UI to start integrating with APPs: In this step you get your API key and integrate with the HRIS APP of your choice from the frontend.
5. Fetch data and make API calls: That’s it! It’s time to start syncing data and making API calls and take advantage of Knit unified APIs and its data models. 

For detailed integration steps with the unified HRIS APIt, visit:

• Getting started with Knit

Security Considerations for HRIS API Integrations

Security happens to be one of the main tenets of HRIS API integration, determining its success and effectiveness. As HRIS API integration facilitates transmission, exchange and storage of sensitive employee data and related information, security is of utmost importance. 

‍

HRIS API endpoints are highly vulnerable to unauthorized access attempts. The lack of robust security protocols, these vulnerabilities can be exploited and attackers can gain access to sensitive HR information. On the one hand, this can lead to data breaches and public exposure of confidential employee data. On the other hand, it can disrupt the existing systems and create havoc. Here are the top security considerations and best practices to keep in mind for HRIS API integration. 

Broken authentication tokens and unauthorized access

Authentication is the first step to ensure HRIS API security. It seeks to verify or validate the identity of a user who is trying to gain access to an API, and ensures that the one requesting the access is who they claim to be. The top authentication protocols include:

‍

• OAuth: It is commonly used to grant third-party applications limited access to user data from other services without exposing user credentials with the third party. It uses access tokens, which are temporary and short lived. 
• Bearer tokens: They are stateless, time-bound access tokens which are simple for one time use, but need to be protected as anyone with access to them can access the API. 
• API keys: Facilitating server-to-server communication, these long-lived secret keys are ideal for trusted parties or internal use. 
• JSON Web Tokens: A token-based authentication method with a self-contained nature, facilitates scalable and secure access. 
• Basic Auth: Involves sending a username and password in the API request header in the form of Base64-encoded credentials.

‍

Most authentication methods rely on API tokens. However, when they are not securely generated, stored, or transmitted, they become vulnerable to attacks. Broken authentication can grant access to attackers, which can cause session hijacking, giving the attackers complete control over the API session. Hence, securing API tokens and authentication protocols is imperative. Practices like limiting the lifespan of your tokens/API keys, via time-based or event-based expiration as well as securing credentials in secret vault services can. 

Data exposure during transmission

As mentioned, HRIS API integration involves transmission and exchange of sensitive and confidential employee information. However, if the data is not encrypted during transmission it is vulnerable to attacker interception. This can happen when APIs use insecure protocols (HTTP instead of HTTPS), data is transmitted as plain text without encryption, there is insufficient data masking and validation. 

‍

To facilitate secure data transmission, it is important to use HTTPS, which uses Transport Layer Security (TLS) or its predecessor, Secure Sockets Layer (SSL), to encrypt data and can only be decrypted when it reaches the intended recipient. 

Input validation failure

Input validation failures can increase the incidence of injection attacks in HRIS API integrations. These attacks, primarily SQL injection and cross-site scripting (XSS), manipulate input data or untrusted data is injected into the database queries. This enables attackers to execute unauthorized database operations, potentially accessing or modifying sensitive information.

‍

Practices like input validation, output encoding, and the principle of least privilege, can help safeguard against injection vulnerabilities. Similarly, for database queries, using parameterized statements instead of injecting user inputs directly into SQL queries, can help mitigate the threat. 

Denial of service attacks and rate limiting

HRIS APIs are extremely vulnerable to denial of service (DoS) attacks where attackers flood your systems with excessive requests which it is not able to process, leading to disruption and temporarily restricts its functionality. Human errors, misconfigurations or even compromised third party applications can lead to this particular security challenge. 

‍

Rate limiting and throttling are effective measures that help prevent the incidence of DoS attacks, protecting APIs against excessive or abusive use and facilitating equitable request distribution between customers. While rate limiting restricts the number of requests or API calls that can be made in a specified time period, throttling slows down the processing of requests, instead of restricting them. Together, these act as robust measures to prevent excessive use attacks by perpetrators, and even protects against brute-force attacks. 

Third party security risks and ongoing threats

Third party security concerns i.e. how secure or vulnerable the third-party applications which you are integrating with, have a direct impact on the security posture of your HRIS API integration. Furthermore, threats and vulnerabilities come in without any prompt, making them unwanted guests. 

‍

To address the security concerns of third-party applications, it is important to thoroughly review the credibility and security posture of the software you integrate with. Furthermore, be cautious of the level of access you grant, sticking to the minimum requirement. It is equally important to monitor security updates and patch management along with a prepared contingency plan to mitigate the risk of security breaches and downtime in case the third-party application suffers a breach. 

‍

Furthermore, API monitoring and logging are critical security considerations for HRIS API integration. While monitoring involves continuous tracking of API traffic, logging entails maintaining detailed historical records of all API interactions. Together they are invaluable for troubleshooting, debugging, fostering trigger alerts in case security thresholds have been breached. In addition, regular security audits and penetration testing are extremely important. While security audits ensure the review of an API's design, architecture, and implementation to identify security weaknesses, misconfigurations, and best practice violations, penetration testing simulates cyberattacks to identify vulnerabilities, weaknesses, and potential entry points that malicious actors could exploit. These practices help mitigate ongoing security threats and facilitate API trustworthiness. 

Security with Knit’s HRIS API

When dealing with a large number of HRIS API integrations, security considerations and challenges increase exponentially. In such a situation, a unified API like Knit can help address all concerns effectively. Knit’s HRIS API ensures safe and high quality data access by:

‍

• Complying with industry best practices and security standards with SOC2, GDPR and ISO27001 certifications. 
• Monitoring Knit's infrastructure continuously with the finest intrusion detection systems. 
• Being the only unified API in the market that does not store any of your end user’s data in its servers.
• Encrypting all data doubly, when in transit and when at rest.
• Facilitating an additional layer of application security for encrypting PII and user credentials.
• Using a detailed Logs, Issues, Integrated Accounts and Syncs page to monitor and manage all integrations and keep track of every API request, call or data sync. 

HRIS API Use Cases: Real-World Examples

Here’s a quick snapshot of how HRIS integration can be used across different scenarios.

HRIS integration for ATS tools

ATS or applicant tracking system can leverage HRIS integration to ensure that all important and relevant details about new employees, including name, contact information, demographic and educational backgrounds, etc. are automatically updated into the customer’s preferred HRIS tool without the need to manually entering data, which can lead to inaccuracies and is operationally taxing. ATS tools leverage the write HRIS API and provide data to the HR tools in use.   

‍

Examples: Greenhouse Software, Workable, BambooHR, Lever, Zoho

HRIS integration for payroll software

Payroll software plays an integral role in any company’s HR processes. It focuses on ensuring that everything related to payroll and compensation for employees is accurate and up to date. HRIS integration with payroll software enables the latter to get automated and real time access to employee data including time off, work schedule, shifts undertaken, payments made on behalf of the company, etc. 

‍

At the same time, it gets access to employee data on bank details, tax slabs, etc. Together, this enables the payroll software to deliver accurate payslips to its customers, regarding the latter’s employees. With automated integration, data sync can be prone to errors, which can lead to faulty compensation disbursal and many compliance challenges. HRIS integration, when done right, can alert the payroll software with any new addition to the employee database in real time to ensure setting up of their payroll immediately. At the same time, once payslips are made and salaries are disbursed, payroll software can leverage HRIS integration to write back this data into the HR software for records. 

‍

‍Examples: Gusto, RUN Powered by ADP, Paylocity, Rippling

HRIS integration for employee onboarding/ offboarding software

Employee onboarding software uses HRIS integration to ensure a smooth onboarding process, free of administrative challenges. Onboarding tools leverage the read HRIS APIs to get access to all the data for new employees to set up their accounts across different platforms, set up payroll, get access to bank details, benefits, etc.

‍

With HRIS integrations, employee onboarding software can provide their clients with automated onboarding support without the need to manually retrieve data for each new joiner to set up their systems and accounts. Furthermore, HRIS integration also ensures that when an employee leaves an organization, the update is automatically communicated to the onboarding software to push deprovisioning of the systems, and services. This also ensures that access to any tools, files, or any other confidential access is terminated. Manually deprovisioning access can lead to some manual errors, and even cause delays in exit formalities. 

‍

Examples: Deel, Savvy, Sappling

Ease of communication and announcements

With the right HRIS integration, HR teams can integrate all relevant data and send out communication and key announcements in a centralized manner. HRIS integrations ensure that the announcements reach all employees on the correct contact information without the need for HR teams to individually communicate the needful. 

HRIS integration for LMS tools

LMS tools leverage both the read and write HRIS APIs. On the one hand, they read or get access to all relevant employee data including roles, organizational structure, skills demand, competencies, etc. from the HRIS tool being used. Based on this data, they curate personalized learning and training modules for employees for effective upskilling. Once the training is administered, the LMS tools again leverage HRIS integrations to write data back into the HRIS platform with the status of the training, including whether or not the employee has completed the same, how did they perform, updating new certifications, etc. Such integration ensures that all learning modules align well with employee data and profiles, as well as all training are captured to enhance the employee’s portfolio. 

‍

Example: TalentLMS, 360Learning, Docebo, Google Classroom

HRIS integration for workforce management and scheduling tools 

Similar to LMS, workforce management and scheduling tools utilize both read and write HRIS APIs. The consolidated data and employee profile, detailing their competencies and training undertaken can help workforce management tools suggest the best delegation of work for companies, leading to resource optimization. On the other hand, scheduling tools can feed data automatically with HRIS integration into HR tools about the number of hours employees have worked, their time off, free bandwidth for allocation, shift schedules etc. HRIS integration can help easily sync employee work schedules and roster data to get a clear picture of each employee’s schedule and contribution. 

‍

Examples: QuickBooks Time, When I Work

HRIS integration for benefits administration tools

HRIS integration for benefits administration tools ensures that employees are provided with the benefits accurately, customized to their contribution and set parameters in the organization. Benefits administration tools can automatically connect with the employee data and records of their customers to understand the benefits they are eligible for based on the organizational structure, employment type, etc. They can read employee data to determine the benefits that employees are entitled to. Furthermore, based on employee data, they feed relevant information back into the HR software, which can further be leveraged by payroll software used by the customers to ensure accurate payslip creation. 

‍

‍Examples: TriNet Zenefits, Rippling, PeopleKeep, Ceridian Dayforce

HRIS integration for workforce planning tools

Workforce planning tools essentially help companies identify the gap in their talent pipeline to create strategic recruitment plans. They help understand the current capabilities to determine future hiring needs. HRIS integration with such tools can help automatically sync the current employee data, with a focus on organizational structure, key competencies, training offered, etc. Such insights can help workforce planning tools accurately manage talent demands for any organization. At the same time, real time sync with data from HR tools ensures that workforce planning can be updated in real time. 

‍

HRIS API Integration Error Handling

There are several reasons why HRIS API integrations fail, highlighting that there can be a variety of errors. Invariably, teams need to be equipped to efficiently handle any integration errors, ensuring error resolution in a timely manner, with minimal downtime. Here are a few points to facilitate effective HRIS API integration error handling. 

Understand the types of errors

Start with understanding the types of errors or response codes that come in return of an API call. Some of the common error codes include:

‍

• 404 Not Found: The requested resource doesn’t exist or isn’t available
• 429 Too Many Requests: API call request rate limit has been reached or exceeded
• 401 Unauthorized: Lack of authorization or privileges to access the particular resource
• 500 Internal Server Error: Issue found at the server’s end

‍

While these are some, there are other error codes which are common in nature and, thus, proactive resolution should be available. 

Configure the monitoring system to incorporate all error details

All errors are generally captured in the monitoring system the business uses for tracking issues. For effective HRIS API error handling, it is imperative that the monitoring system be configured in such a way that it not only captures the error code but also any other relevant details that may be displayed along with it. These can include a longer descriptive message detailing the error, a timestamp, suggestion to address the error, etc. Capturing these can help developers with troubleshooting the challenge and resolve the issues faster. 

Use exponential back-offs to increase API call intervals

This error handling technique is specifically beneficial for rate limit errors or whenever you exceed your request quota. Exponential backoffs allow users to retry specific API calls at an increasing interval to retrieve any missed information. The request may be retrieved in the subsequent window. This is helpful as it gives the system time to recover and reduces the number of failed requests due to rate limits and even saves the costs associated with these unnecessary API calls. 

Test, document and review error handling process

It is very important to test the error handling processes by running sandbox experiments and simulated environment testing. Ideally, all potential errors should be tested for, to ensure maximum efficiency. However, in case of time and resource constraints, the common errors mentioned above, including HTTP status code errors, like 404 Not Found, 401 Unauthorized, and 503 Service Unavailable, must be tested for. 

In addition to robust testing, every step of the error handling process must be documented. Documentation ensures that even in case of engineering turnover, your HRIS API integrations are not left to be poorly maintained with new teams unable to handle errors or taking longer than needed. At the same time, having comprehensive error handling documentation can make any knowledge transfer to new developers faster. Ensure that the documentation not only lists the common errors, but also details each step to address the issues with case studies and provides a contingency plan for immediate business continuity. 

‍

Furthermore, reviewing and refining the error handling process is imperative. As APIs undergo changes, it is normal for initial error handling processes to fail and not perform as expected. Therefore, error handling processes must be consistently reviewed and upgraded to ensure relevance and performance. 

API error handling with Knit

Knit’s HRIS API simplifies the error handling process to a great extent. As a unified API, it helps businesses automatically detect and resolve HRIS API integration issues or provide the customer-facing teams with quick resolutions. Businesses do not have to allocate resources and time to identify issues and then figure out remedial steps. For instance, Knit’s retry and delay mechanisms take care of any API errors arising due to rate limits. 

TL:DR

It is evident that HRIS API integration is no longer a good to have, but an imperative for businesses to manage all employee related operations. Be it integrating HRIS and other applications internally or offering customer facing integrations, there are several benefits that HRIS API integration brings along, ranging from reduced human error to greater productivity, customer satisfaction, etc. When it comes to offering customer-facing integrations, ATS, payroll, employee onboarding/ offboarding, LMS tools are a few among the many providers that see value with real world use cases. 

‍

However, HRIS API integration is fraught with challenges due to the diversity of HR providers and the different protocols, syntax, authentication models, etc. they use. Scalining integrations, testing across different environments, security considerations, data normalization, all create multidimensional challenges for businesses. Invariably, businesses are now going the unified API way to build and manage their HRIS API integration. Knit’s unified HRIS API ensures:

‍

• One unified API to connect with all HRIS tools you need
• Single unified data model for seamless data normalization and exchange
• Compliance to the highest security standards like SOC2, GDPR, ISO27001, HIPAA
• Option to authenticate the way you want, including, OAuth, API key or a username-password based authentication
• 100% webhooks architecture that send out notification whenever updated data is available
• Guaranteed scalability and delivery of HR data irrespective of data load
• High level of security as Knit doesn’t store a copy of your data
• Option to read and write data from any app from any HRIS category
• Option to limit data sync and API calls to only what you need
• Double encryption when in transit and when at rest with addition PII layer
• Detailed Logs, Issues, Integrated Accounts and Syncs page to easily monitor HRIS integrations
• Custom fields to manage any non-standard HRIS data

‍

Knit’s HRIS API ensures a high ROI for companies with a single type of authentication, pagination, rate limiting, and automated issue detection making the HRIS API integration process simple.

‍

Top 5 Alternatives to tryfinch

‍

TL:DR:

Finch is a leading unified API player, particularly popular for its connectors in the employment systems space, enabling SaaS companies to build 1: many integrations with applications specific to employment operations. This translates to the ease for customers to easily leverage Finch’s unified connector to integrate with multiple applications in HRIS and payroll categories in one go. Invariably, owing to Finch, companies find connecting with their preferred employment applications (HRIS and payroll) seamless, cost-effective, time-efficient, and overall an optimized process. While Finch has the most exhaustive coverage for employment systems, it's not without its downsides - most prominent being the fact that a majority of the connectors offered are what Finch calls “assisted” integrations. Assisted essentially means a human-in-the-loop integration where a person has admin access to your user's data and is manually downloading and uploading the data as and when needed.

Pros and cons of Finch

Why chose Finch (Pros)

● Ability to scale HRIS and payroll integrations quickly

● In-depth data standardization and write-back capabilities

● Simplified onboarding experience within a few steps

However, some of the challenges include(Cons):

● Most integrations are human-assisted instead of being true API integrations

● Integrations only available for employment systems

● Limited flexibility for frontend auth component

● Requires users to take the onus for integration management

‍

Pricing: Starts at $35/connection per month for read only apis; Write APIs for employees, payroll and deductions are available on their scale plan for which you’d have to get in touch with their sales team.

Now let's look at a few alternatives you can consider alongside finch for scaling your integrations

Finch alternative #1: Knit

‍

Knit is a leading alternative to Finch, providing unified APIs across many integration categories, allowing companies to use a single connector to integrate with multiple applications. Here’s a list of features that make Knit a credible alternative to Finch to help you ship and scale your integration journey with its 1:many integration connector:

‍

Pricing: Starts at $2400 Annually

‍

Here’s when you should choose Knit over Finch:

‍

● Wide horizontal and deep vertical coverage: Knit not only provides a deep vertical coverage within the application categories it supports, like Finch, however, it also supports a wider horizontal coverage of applications, higher than that of Finch. In addition to applications within the employment systems category, Knit also supports a unified API for ATS, CRM, e-Signature, Accounting, Communication and more. This means that users can leverage Knit to connect with a wider ecosystem of SaaS applications.

‍

● Events-driven webhook architecture for data sync: Knit has built a 100% events-driven webhook architecture, which ensures data sync in real time. This cannot be accomplished using data sync approaches that require a polling infrastructure. Knit ensures that as soon as data updates happen, they are dispatched to the organization’s data servers, without the need to pull data periodically. In addition, Knit ensures guaranteed scalability and delivery, irrespective of the data load, offering a 99.99% SLA. Thus, it ensures security, scale and resilience for event driven stream processing, with near real time data delivery.

‍

● Data security: Knit is the only unified API provider in the market today that doesn’t store any copy of the customer data at its end. This has been accomplished by ensuring that all data requests that come are pass through in nature, and are not stored in Knit’s servers. This extends security and privacy to the next level, since no data is stored in Knit’s servers, the data is not vulnerable to unauthorized access to any third party. This makes convincing customers about the security potential of the application easier and faster.

‍

● Custom data models: While Knit provides a unified and standardized model for building and managing integrations, it comes with various customization capabilities as well. First, it supports custom data models. This ensures that users are able to map custom data fields, which may not be supported by unified data models. Users can access and map all data fields and manage them directly from the dashboard without writing a single line of code. These DIY dashboards for non-standard data fields can easily be managed by frontline CX teams and don’t require engineering expertise.  

‍

● Sync when needed: Knit allows users to limit data sync and API calls as per the need. Users can set filters to sync only targeted data which is needed, instead of syncing all updated data, saving network and storage costs. At the same time, they can control the sync frequency to start, pause or stop sync as per the need.

‍

● Ongoing integration management: Knit’s integration dashboard provides comprehensive capabilities. In addition to offering RCA and resolution, Knit plays a proactive role in identifying and fixing integration issues before a customer can report it. Knit ensures complete visibility into the integration activity, including the ability to identify which records were synced, ability to rerun syncs etc.

‍

As an alternative to Finch, Knit ensures:

● No-Human in the loop integrations

● No need for maintaining any additional polling infrastructure

● Real time data sync, irrespective of data load, with guaranteed scalability and delivery

● Complete visibility into integration activity and proactive issue identification and resolution

● No storage of customer data on Knit’s servers

● Custom data models, sync frequency, and auth component for greater flexibility

‍

Finch alternative #2: Merge

Another leading contender in the Finch alternative for API integration is Merge. One of the key reasons customers choose Merge over Finch is the diversity of integration categories it supports.

Pricing: Starts at $7800/ year and goes up to $55K

‍

Why you should consider Merge to ship SaaS integrations:

‍

● Higher number of unified API categories; Merge supports 7 unified API categories, whereas Finch only offers integrations for employment systems

● Supports API-based integrations and doesn’t focus only on assisted integrations (as is the case for Finch), as the latter can compromise customer’s PII data

● Facilitates data sync at a higher frequency as compared to Finch; Merge ensures daily if not hourly syncs, whereas Finch can take as much as 2 weeks for data sync

‍

However, you may want to consider the following gaps before choosing Merge:

‍

● Requires a polling infrastructure that the user needs to manage for data syncs

● Limited flexibility in case of auth component to customize customer frontend to make it similar to the overall application experience

● Webhooks based data sync doesn’t guarantee scale and data delivery

‍

Finch alternative #3: Workato

‍

Workato is considered another alternative to Finch, albeit in the traditional and embedded iPaaS category.

‍

Pricing: Pricing is available on request based on workspace requirement; Demo and free trial available

‍

Why you should consider Workato to ship SaaS integrations:

‍

● Supports 1200+ pre-built connectors, across CRM, HRIS, ticketing and machine learning models, facilitating companies to scale integrations extremely fast and in a resource efficient manner

● Helps build internal integrations, API endpoints and workflow applications, in addition to customer-facing integrations; co-pilot can help build workflow automation better

● Facilitates building interactive workflow automations with Slack, Microsoft Teams, with its customizable platform bot, Workbot

However, there are some points you should consider before going with Workato:

● Lacks an intuitive or robust tool to help identify, diagnose and resolve issues with customer-facing integrations themselves i.e., error tracing and remediation is difficult

● Doesn’t offer sandboxing for building and testing integrations

● Limited ability to handle large, complex enterprise integrations

‍

Finch alternative #4: Paragon

Paragon is another embedded iPaaS that companies have been using to power their integrations as an alternative to Finch.

Pricing: Pricing is available on request based on workspace requirement;

‍

Why you should consider Paragon to ship SaaS integrations:

‍

● Significant reduction in production time and resources required for building integrations, leading to faster time to market

● Fully managed authentication, set under full sets of penetration and testing to secure customers’ data and credentials; managed on-premise deployment to support strictest security requirements

● Provides a fully white-labeled and native-modal UI, in-app integration catalog and headless SDK to support custom UI

However, a few points need to be paid attention to, before making a final choice for Paragon:

● Requires technical knowledge and engineering involvement to custom-code solutions or custom logic to catch and debug errors

● Requires building one integration at a time, and requires engineering to build each integration, reducing the pace of integration, hindering scalability

● Limited UI/UI customization capabilities

‍

Finch alternative #5: Tray.io

‍

Tray.io provides integration and automation capabilities, in addition to being an embedded iPaaS to support API integration.

Pricing: Supports unlimited workflows and usage-based pricing across different tiers starting from 3 workspaces; pricing is based on the plan, usage and add-ons

‍

Why you should consider Tary.io to ship SaaS integrations:

‍

● Supports multiple pre-built integrations and automation templates for different use cases

● Helps build and manage API endpoints and support internal integration use cases in addition to product integrations

● Provides Merlin AI which is an autonomous agent to build automations via chat interface, without the need to write code

However, Tray.io has a few limitations that users need to be aware of:

● Difficult to scale at speed as it requires building one integration at a time and even requires technical expertise

● Data normalization capabilities are rather limited, with additional resources needed for data mapping and transformation

● Limited backend visibility with no access to third-party sandboxes

‍

TL:DR

We have talked about the different providers through which companies can build and ship API integrations, including, unified API, embedded iPaaS, etc. These are all credible alternatives to Finch with diverse strengths, suitable for different use cases. Undoubtedly, the number of integrations supported within employment systems by Finch is quite large, there are other gaps which these alternatives seek to bridge:

‍

● Knit: Providing unified apis for different categories, supporting both read and write use cases. A great alternative which doesn’t require a polling infrastructure for data sync (as it has a 100% webhooks based architecture), and also supports in-depth integration management with the ability to rerun syncs and track when records were synced.

● Merge: Provides a greater coverage for different integration categories and supports data sync at a higher frequency than Finch, but still requires maintaining a polling infrastructure and limited auth customization.

● Workato: Supports a rich catalog of pre-built connectors and can also be used for building and maintaining internal integrations. However, it lacks intuitive error tracing and remediation.

● Paragon: Fully managed authentication and fully white labeled UI, but requires technical knowledge and engineering involvement to write custom codes.

● Tray.io: Supports multiple pre-built integrations and automation templates and even helps in building and managing API endpoints. But, requires building one integration at a time with limited data normalization capabilities.

‍

Thus, consider the following while choosing a Finch alternative for your SaaS integrations:

● Support for both read and write use-cases

● Security both in terms of data storage and access to data to team members

● Pricing framework, i.e., if it supports usage-based, API call-based, user based, etc.

● Features needed and the speed and scope to scale (1:many and number of integrations supported)

Depending on your requirements, you can choose an alternative which offers a greater number of API categories, higher security measurements, data sync (almost in real time) and normalization, but with customization capabilities.

‍

‍

‍

‍

‍

‍

As hiring needs for organizations become more complex, assessing candidates in a holistic and comprehensive manner is more critical than ever. Fortunately, multiple assessment software have surfaced in the recent past, enabling organizations to carry out assessments in the most effective and efficient manner. Leveraging technology, gamification and other advances, such tools are able to help organizations ensure that a candidate is a perfect fit for the role, skills, company culture and all other parameters. 

‍

However, to make the best use of assessment software, it is important to integrate data and information from them across other platforms being used for operational efficiency and faster turnaround in recruitment and onboarding. Here, assessment API integration plays a major role. 

‍

When organizations integrate data from the assessment API with other applications, including ATS, HRIS, interview scheduling, etc., they are able to optimize their recruitment workflow with a high degree of automation. 

‍

In this article, we will discuss the different aspects of assessment API, its integration use cases, key data models and the different ways in which you can accomplish seamless integration. 

Assessment API Data Models

To ensure that you understand the different assessment APIs well, it is important to comprehend the data models or fields that are commonly used. One of the major reasons that the knowledge of data models is imperative is to facilitate data transformation and normalization during data sync. Here are the common data models for assessment APIs:

Candidate name

This data model focuses on the name of the candidate to whom a particular assessment will be administered and all records pertaining to the candidate will be stored. It can also be associated with a unique candidate ID to prevent any confusion in case of duplication of names. 

Candidate profile

The next data model captures the profile of the candidate. From an assessment software perspective, the focus is on a candidate’s professional profile, prior work experience, qualifications, certifications, competencies, etc. Such details help in determining the right assessments for each candidate based on their experience and the role for which they are being assessed.  

Candidate contact information

This data field keeps the details or contact information for all candidates, including phone number, email address, etc. The contact information ensures that the candidate’s can be easily informed about their assessment schedule, any changes in the schedule, results, status, etc. it facilitates smooth communication between the assessment software and the candidate. 

Candidate profile picture

Most assessment software capture candidate pictures to ensure authenticity during assessments or training. Candidate profile pictures in assessment software databases help the latter to prevent proxy attendance during interviews or assessments and address any potential foul play. 

Job type

The next data model captures the nature of employment or the type of job. Today, in addition to full-time employees, organizations are increasingly hiring consultants, gig workers and even contractual employees. The assessment requirements for each one of them can be varied. Thus, the assessment software has a data model to capture the job type to ensure appropriate assessments. 

Job information

Assessment API captures job information or job details as an important data model. Put simply, this model has all details about the role being assessed for, the requirements, skills, competencies, and other aspects which need to be assessed. As a data model or field, job information contains all aspects of the job that need to be matched when candidates are assessed. 

Job department and managers

Next in line is the data model which focuses on the job department and managers. This particular field captures the department for which the candidate has applied for and the hiring managers. The details of hiring managers are important because the results of the assessment tests have to be sent to them. 

Assessment stages

Most assessment software have a few stages that a candidate undergoes. It can start from a normal personality test and go on to psychometric evaluations, coding tests, to personal interviews. As a data model, assessment stages help hiring managers understand where the candidates stand in the hiring pipeline and how close or far they are from closing a particular role at hand. 

Assessment list

The next data model captures all the types of assessments that are available as a part of the assessment software. This field has a repository of different assessments that can be administered. 

Scorecard

Once the assessment is administered, an important data model is the scorecard. This captures how the candidate performed for a particular assessment. The scorecard format or type can be different and unique for each assessment type. In some, it can be an absolute and objective score, while some others might give a more subjective outcome, determining the suitability of the candidate for the role. 

Assessment result

The assessment result as a data model captures the final verdict for the candidate. More often than not, hiring managers can update the result as selected, rejected or any other based on the scorecard and other evaluations undertaken, post which the data can be integrated into the next workflow software. 

Assessment attachment

This data field or data model captures any attachments that come along with a particular assessment test. Some tests might require candidates to submit their assessments as an attachment or external document. This field contains all such attachments which can be consulted during final hiring decisions. 

Assessment status

The assessment status data model captures the status of the assessment test for a particular candidate. It captures if the test has been provided to the candidate, whether or not they have completed the same, etc. 

Top Assessment Applications

Now that there is a clear understanding of the different assessment software data models, let’s quickly look at some of the top assessment applications available in the market today, which can be integrated with different software like ATS, HRIS, LMS, etc. 

‍

‍

Assessment API Integration: Top Use Cases

Assessment software is a part of the larger ecosystem of software that companies today use to manage their people's operations. Invariably, there are several other tools and software in the market today, which when integrated with assessment APIs can lead to operational efficiency and smooth HR and related processes. There are several categories of tools out there which either feed data into assessment APIs (write APIs) or get access to data from assessment APIs (read APIs). Integration ensures that such data syncs are automated and do not require any manual interview, which can be prone to errors, time consuming and operationally taxing. Here are some of the top use cases for assessment API integration across different software. 

Assessment API integration for ATS tools

Assessment API integration is very critical for ATS or applicant tracking systems. ATS tools and platforms have all the required information about candidates, including their name, profile, pictures, contact information, etc. Assessment API integration with ATS tools ensures that the assessment read API can get access to all these details automatically without any manual intervention. At the same time, integration also facilitates real-time information updation in assessment tools, which can set up assessments for new applicants almost immediately. This leads to faster turnaround. Furthermore, the assessment write APIs can feed information back to the ATS tools with the assessment results and scorecards to help update the candidate’s status in the recruitment flow. 

‍

Examples: Greenhouse Software, Workable, BambooHR, Lever, Zoho

Assessment API integration for candidate screening tools

Candidate screening tools help organizations determine whether or not a candidate is ideal or right for the role in question. Integration with assessment software ensures that data about a candidate’s performance in an assessment test is automatically synced for screening managers to assess the skills, competencies and abilities of the candidate and its relevance to the open position. Furthermore, assessment API integration with candidate screening tools ensures that the latter have real time access to candidate assessment results for immediate hiring decision making, based on evidence backed data for smart hiring. 

‍

Examples: 

Assessment API integration for HRIS tools

Assessment API integration with HRIS tools is a no brainer. Once a candidate clears the assessments and is offered a job at an organization, it is essential to capture the results from the assessments in the HRIS platform. Here, the assessment write APIs play an important role. They help HR teams get access to all the relevant information about an employee based on different personality, psychometric, behavioral, cognitive tests to help them capture employee records which are robust and comprehensive. Automated integration of data from assessment tools to HRIS platforms ensures that no human error or bias crawls in when assessment data is being entered into HRIS portals. Furthermore, since many parts of an assessment test can be sensitive, such integration ensures that data exchange is confidential and on a need to know basis only. 

‍

Examples: BambooHR, Namely, SAP SuccessFactors, Gusto

Assessment API integration for interview scheduling tools

Most companies today leverage interview scheduling tools to automate their entire interview processes, including blocking calendars, managing schedules, etc. For interview scheduling tools, integration with assessment APIs is important to ensure that all interviews with candidates can be scheduled effectively, keeping in my mind both interviewer and interviewee schedules. Interview scheduling tools can leverage assessment read APIs to understand the assessment availability and dates to schedule the interview. Furthermore, once the interview is scheduled, assessment write APIs can help provide updates on whether or not the candidate attended the interview, status, next steps to help interview scheduling tools effectively conduct interactions with candidates as needed. 

‍

Examples: Calendly, Sense, GliderAI, YouCanBookMe, Paradox

Assessment API integration for LMS tools 

While most assessment software have use cases in the pre-employment stages, their utility can also transcend into post employment phases as well. The LMS tools can easily leverage assessment read APIs to understand the type of assessment tests available which can be used for internal training purposes. Furthermore, candidate performance in pre-employment assessment tests can be used as a baseline to define the types of training required and areas for upskilling. Overall, this integration can help identify the learning needs for the organization and clarify the assessments available for further investigation. At the same time, once the assessments are administered, the assessment write API can automatically sync the relevant data and results for post employment assessment on whether or not employees participated in the assessments, results, gaps, etc. to the LMS tools for better decision making on employee training and development. 

‍

Example: TalentLMS, 360Learning, Docebo, Google Classroom 

Assessment API integration for talent management tools

Talent management and workforce planning tools are integral when it comes to succession planning for any organization. Assessments conducted, both pre and post employment can greatly help in determining the talent needs for any organization. Talent management tools can leverage assessment read APIs to understand how their existing or potential talent is performing along areas critical to the organization. Any gaps in the talent or consistent poor performance in a particular area of assessment can then be identified to adopt corrective measures. Assessment API integration can help talent management tools effectively understand the talent profile in their organization, which can further help in better succession planning and talent analytics. 

‍

Examples: ClearCompany, Deel, ActivTrak

Unified Assessment API Integration: All You Need to Know

There are several ways companies can achieve assessment API integration to suit their use cases. Right from building integrations in-house for each assessment tool to practices like workflow automation tools, there are several ways to integrate. However, as the number of customers and integration needs increase exponentially, going for a unified assessment API for integration is the best move. Here are a few instances when choosing a unified API for assessment software integration makes sense. Use unified assessment API when you:

‍

• Wish to integrate with multiple assessment software based on your customer needs and developing point to point integration with each one is not viable
• Have a large customer base and their integration requests for new assessment software is increasing
• Need to deliver integrations in a short span of time and you lack dedicated engineering bandwidth in-house
• Want to achieve assessment API integration at a lower cost with faster time to market
• Don’t want to take the burden of ongoing maintenance and management of each integration
• Want to skip the effort that goes into reading through API documentation for each integration
• Want to normalize data across assessment platforms and ensure that this transformation process is 10X faster than you internal processes
• Want to ensure complete security, especially due to the nature of sensitive information in question
• Seek real-time sync and exchange of data for immediate action or the flexibility to customize syncs as per your needs
• Want to skip the process of learning about different authentication keys, rate limits, etc. for different APIs

‍

Now that you know a unified assessment API is the best and the most effective for you to build integrations with assessment software, go through the following questions to choose the best unified assessment API for your organization. 

What are the data models?

The ideal unified API normalizes and syncs data into a unified data model and facilitates data transformation 10x faster. While most fields are common and a unified model works, choose a unified assessment API which also gives you the flexibility to add some custom data models which may not align with the standard data models available. 

What are the rate limits?

Each unified API will offer rate limits, which is the number of API requests or data sync requests you can make in a given period of time. Having an optimum rate limit is extremely important. Having a very high rate limit, in which many requests can be made can lead to potential DDoS attacks and other vulnerabilities. Whereas, having a very low rate limit, where only a handful API requests can be made, might lead to inefficiencies and data inaccuracies. Therefore, gauge the rate limits offered to check if they align with your needs or if they can be customized for you. 

How secure is the integration process?

Next, any unified assessment API you choose should be high on security. On the one hand, check for compliance with all certifications and global standards. On the other hand, look out for comprehensive data encryption, which involves encrypting data at rest and in transit. When looking at security, do check the level of authentication and authorization available.  

What kind of post integration support is available?

Building integrations is followed by the operationally and technically draining tasks of managing integrations. Integration maintenance and management can take anywhere between 5-10 hours of your engineering bandwidth. Therefore, choose a unified assessment API provider which provides you with maintenance support. You should be able to manage the health of all your integrations with a robust track of all API calls, requests, etc. 

What is the sync frequency?

As data sync is the most important part of assessment API integration, check the sync frequency offered by the unified API. While real-time sync, powered by a webhook architecture which ensures real-time data transfer, without any polling infrastructure is ideal. It is equally important to have something which can be customized and allows you to set the sync frequency as per your needs. 

How easy is it to scale?

The key purpose of a unified assessment API is to scale as fast as possible and ensure all customer assessment tools are integrated with. Therefore, you must check the breadth of assessment API integrations being offered. At the same time, explore how open and forthcoming the unified API provider is to custom integrations for you if needed. This also needs to be weighted against the time taken for each new integration and any cost associated with the same. 

Can it take a high data load?

Finally, as you add more assessment API integrations and the number of customers using the same increase, the data load for sync will experience an exponential rise. Thus, your unified assessment API must facilitate guaranteed scalability with quality sync, irrespective of the data load. Without the same, there are chances of data corruption. 

Knit: Unified Assessment API

As a leading unified assessment API, Knit has the right tick mark for all the considerations mentioned above and much more. Here’s why you should consider Knit for your assessment API integration needs:

‍

• Unified data model which normalizes data with option to customize some fields
• Double encryption of data with encryption for PII and user credentials
• Compliance with  SOC2, GDPR, ISO27001
• No storage of a copy of any data that passes through Knit
• Webhook architecture for real time data sync irrespective of data load
• Option to customize sync frequency whenever needed
• Availability of OAuth, API key or a username-password based authentication
• Bi-directional data sync to read and write from any assessment software
• Detailed Logs, Issues, Integrated Accounts and Syncs page for integration management

‍

Book a demo today to learn about the other ways in which Knit can be your ideal unified assessment API partner, how it works and anything else you need to know!

Wrapping up: TL:DR

Integrating with assessment APIs can help different companies and platforms unlock value to better streamline their operations. Assessment API integration can facilitate bi-directional sync of data between assessment tools and other applications. While there are several ways to achieve such integration, a unified API is one of the top contenders as it facilitates data normalization, high levels of security, guaranteed scalability, seamless maintenance and management and real time data syncs. 

If you are looking to integrate multiple HRIS, payroll and ATS apps with a single API key, check out Knit API. If you are looking to learn more about key payroll API concepts, data models and use cases, keep reading

‍

As the nature of employment is constantly changing with dynamic employee benefit expectations, organizational payroll is seeing constant transformation. At the same time, payroll data is no longer used only for paying employees, but is increasingly being employed for a variety of other purposes. 

This diversification and added complexities of payroll has given rise to payroll APIs which are integral in bringing together the employment ecosystem for businesses to facilitate smooth transactions. 

What are payroll APIs?

Like all other APIs or application programming interfaces, payroll APIs help companies integrate their different applications or platforms that they use to manage employee payment details together for a robust payroll system. 

Essentially, it enables organizations to bring together details related to salary, benefits, payment schedule etc. and run this data seamlessly to ensure that all employees are compensated correctly and on time, facilitating greater satisfaction and motivation, while preventing any financial challenges for the company. 

Payroll concepts and information

To build or use any payroll API or HRIS integration, it is important that you understand the key payroll concepts and the information you will need to collect for effective execution. Since payroll APIs are domain specific, lack of knowledge of these concepts will make the process of integration complicated and slow. Thus, here is a quick list of concepts to get started.

1. Frequency and repetition 

The first concept you should start with focuses on understanding the frequency and repetition of payments. There are multiple layers to understand here. 

First, understand the frequency. In technical terms, it is called pay period. This refers to the number of times a payment is made within a specific period. For instance, it could be monthly, twice in a month, four times a month, etc. Essentially, it is how many times a payment is made within a particular period.

Second, is the repetition, also known as payroll runs. Within an organization, some employees are paid on a regular basis, while others might receive a one-time payment for specific projects. A payroll run defines whether or not the payment is recurring. Your payroll run will also constitute a status to help understand whether or not the payment has been made. In case the payment is being calculated, the status will likely be unprocessed. However, once it is complete, the status will change to paid or whatever nomenclature you use. 

2. Pay scale and in-hand pay

As a part of the payroll concepts, it is extremely important for you to understand terms like pay scale, in-hand pay, compensation, pay rate, deduction, reimbursements, etc. We’ll take them one at a time.

Pay scale/ Pay rate

A pay scale or pay rate determines the amount of salary that is due to an employee based on their level of experience, job role, title, tenure with the organization, etc. 

A pay scale or a pay rate can be in the form of an hourly or weekly or even a monthly figure, say INR xx per week or INR yy per hour. It may differ for people with similar experience at the same level, based on their tenure with the company, skills and competencies, etc. 

Compensation

Based on the pay scale or pay rate, a company can calculate the compensation due to any employee. Generally, the math for compensation isn’t linear. Compensation is also referred to as the gross pay which includes the pay rate multiplied by the time period that the employee has worked for along with other benefits like bonuses and commissions that might be due to the employee, based on their terms of employment. 

For instance, some organizations provide a one-time joining bonus, while others have sales incentives for their employees. All of these form a part of the compensation or gross pay. 

Benefits

In addition to the benefits mentioned above, an employee might be eligible for others including a health cover, leave-travel allowance, mental wellness allowance etc. These all together add up to benefits that an employee receives over and above the pay rate. 

Deductions

Within the compensation or the gross pay are parts of deductions, which are not directly paid to the employees. These deductions differ across countries and regions and even based on the size of the company. 

For instance, in India, companies have to deduct PF from the employee’s gross pay which is given to them at the time of retirement. However, if an organization is smaller than 20 people, this compliance doesn’t come into existence. At the same time, based on the pay scale and pay rate, there are tax deductions which are due. 

In-hand pay

The in-hand pay is essentially the amount an employee receives after addition of all due payment and subtraction of the aforementioned deductions. This is the payment that the employee receives in his/ her bank account.

Reimbursements

Another concept within the payroll is reimbursements. There might be some expenses that an employee undertakes based on the requirements of the job, which are not a part of the gross pay. For instance, an employee takes out a client for dinner or is traveling for company work. In such cases, the expenses borne by the employee are compensated to the employee. Reimbursements are generally direct and don’t incur any tax deductions.

3. Cost to employer

The above concepts together add up to the cost to the employer. This refers to how much an employee essentially costs to a company, including all the direct and indirect payments made to them. The calculation starts with the pay scale or pay rate to which other aspects like contribution to benefits and em

Payroll data models/ data schemas 

Now that you have an understanding of the major payroll concepts, you also need to be aware about the key data or information that you will need to comprehend to work on payroll APIs. 

Essentially, there are two types of data models that are most used in payroll APIs. One focuses on the employees and the other on the overall organization or company.

Employee details

From an employee standpoint, any payroll API will need to have the following details:

Location 

The part of the world where the employee resides. You need to capture not only the present but also the permanent address of the employee.

Profile 

Employee profile refers to a basic biography of the concerned person which includes their educational backgrounds, qualifications, experience, areas of expertise, etc. These will help you understand which pay scale they will fit into and define the compensation in a better way. It is equally important to get their personal details like date of birth, medical history, etc. 

ID

An employee ID will help you give a unique identifier to each employee and ensure all payments are made correctly. There might be instances where two or more employees share the same name or other details. An employee ID will help differentiate the two and process their payrolls correctly. 

Dependents 

Information on dependents like elderly parents, spouses and children will help you get a better picture of the employee’s family. This is important from a social security and medicare perspective that is often extended to dependents of employees.

Company details

When it comes to company details, working with a payroll API, you need to have a fair understanding of the organizational structure. The idea is to understand the hierarchy within the organization, the different teams as well as to get manager details for each employee.

A simple use case includes reimbursements. Generally, reimbursements require an approval from the direct reporting manager. Having this information can make your payroll API work effectively.

Top payroll API use cases

Invariably, a payroll API can help you integrate different information related to an employee’s payroll and ensure a smooth payment process. However, it is interesting to note that many SaaS companies are now utilizing this payroll data collected from payroll APIs with HRIS integration to power their operations. Some of the top payroll API use cases include:

1. Insurance and lending

Often, information about payroll and income for individuals is siloed and insurance and lending companies have to navigate through dozens of documents to determine whether or not the individual is eligible for any kind of insurance or loans. Fortunately, with payroll APIs, this becomes easy by enabling several benefits. 

• First, payroll API can help lenders or insurance agents with streamlined information on whether or not the person has the ability to pay the installments or loans. 
• Second, any kind of lending also requires a background verification which payroll APIs with HRIS integration can easily provide. Thus, with payroll APIs, SaaS based insurance and lending companies can easily process verification and loan underwriting. 

2. Accounting

Accounting and tax management companies have for long struggled with manual paperwork to file company taxes which comply with the national and regional norms. With payroll API, SaaS based accounting firms find it extremely easy to access all employee related tax information at one place. They can see the benefits offered to different employees, overall compensation, reimbursements and all other payroll related technicalities which were earlier siloed. 

Armed with this data, courtesy payroll APIs, accounting firms find their work has been highly streamlined as they no longer have to manually document all information and then work to verify its accuracy and compliance.

3. Employee benefit companies

There are several SaaS companies today that are helping businesses set up their benefits plans and services for high levels of employee satisfaction. These employee benefits companies can take help of data from payroll APIs to help businesses customize their benefits packages to best suit employee expectations and trends. 

For instance, you might want to have different benefits for full-time versus contractual employees. With payroll API data, employee benefit companies can help businesses make financially prudent decisions for employee benefits. 

4. Performance management systems

The recent years have seen a rise in the adoption of performance management systems which can help businesses adopt practices for better employee performance. Armed with HRIS and payroll API data from different companies, these companies can identify motivators in payroll for better performance and even help identify rate of absenteeism and causes of poor performance. 

Such SaaS based companies use payroll APIs to understand which pay scale employees take more time off, what their benefits look like and how this gap can be bridge to facilitate better performance. Invariably, here, payroll data can help streamline performance management from a benefits, incentives and compensation standpoint.As well as, it makes HRIS data makes it a one click process to gather all relevant employee information. 

5. Consumer fintech companies

Consumer fintech companies, like those in direct deposit switching, are increasingly leveraging payroll APIs to facilitate their operations. Payroll API integrations allow consumers to directly route their deposits through their payroll with direct deposit switching. The account receiving the deposit is directly linked to the employee’s payroll account, making it easy for consumer fintech companies to increase their transactions, without manual intervention which increases friction and reduces overall value. 

5. Commercial insurance 

Finally, there are SaaS companies that deal with commercial insurance for companies for different purposes. Be it health or any other, payroll API data can help them get a realistic picture of the company’s people posture and their payroll information which can help these commercial insurance companies suggest the best plans for them as well as ensure that the employees are able to make the payments. They can achieve all of this without having to manually process data for all employees across the organization.

Payroll fragmentation challenges

Research shows that the payroll market is poised to grow at a CAGR of 9.2% between 2022 and 2031, reaching $55.69 billion by 2031. 

While the growth is promising, the payroll market is extremely fragmented. Undoubtedly, there are a few players like ADP RUN, Workday, etc. which have a significant market share. However, the top 10 players in the space constitute only about 55%-60% share, which clearly illustrates the presence of multiple other smaller companies. In fact, as you go down from the top 2-3 to the top 10, the market share for individual applications dwindles down to 1% each. 

Here is a quick snapshot of the payroll market segmentation to help understand its fragmented nature and the need for a unified solution to make sense of payroll APIs. 

Before moving on to how payroll fragmentation can be addressed with a unified solution, it is important to understand why this fragmentation exists. The top reasons include:

Changing and diverse employee demographics

First, different businesses have different demographics and industries that they cater to. Irrespective of the features, each business is looking for a payroll solution that provides them with the best pricing based on their number of employees and employment terms. While some might have a large number of full time salaried employees, others might have a large number of contractual workers, while the third kind might have a balanced mix of both. These diverse demographic requirements have given birth to different payroll applications, fragmenting the market. 

Dynamic market conditions

Next, it is important to understand that market conditions and employment terms are constantly in flux. 

• On one hand, the compensation and benefits expectations are continually changing. 
• On the other hand, with the rise of remote and hybrid work, employment models are undergoing transformation. 

Therefore, as businesses need new and fresh approaches to deal with their payroll requirements, a consequent rise of fragmentation can be observed. 

New and tech enabled solutions

Finally, organizations are increasingly adopting white labeled or embedded payroll solutions which enable them to either brand the solutions with their name or embed the API into their existing product. This is enabling market players in other verticals to also enter the payroll market, which further adds to the fragmentation. 

• On one hand, there are completely new SaaS players entering the market to address new business needs and changing market conditions. 
• On the other hand, existing players from other verticals are adding to their capabilities to address payroll requirements. 

Unified API for payroll integration

With so many payroll applications in the market for HRMS integration, it can be extremely daunting for businesses to make sense of all payroll related data. At the same time, it is difficult to manage data exchange between different payroll applications you might be using. Therefore, a unified payroll API can help make the process easy. 

Data normalization

First, the data needs to be normalized. This means that your unified payroll API will normalize and funnel data from all payroll providers about each employee into a consistent, predictable and easy to understand data format or syntax, which can be used. 

Data management

Second, a unified API will help you manage all employee payroll data in the form of unified logs with an API key to ensure that you can easily retrieve the data as and when needed. 

Make informed decisions

Finally, a unified payroll API can help ensure that you are able to make sense of the payroll data and make informed decisions during financial planning and analysis on factors like pay equity, financial prudence, etc. 

Payroll API data with Knit 

As a unified payroll API, Knit can help you easily get access to the following payroll data from different payroll applications that you might be using to facilitate seamless payment processing and payroll planning for the next financial year. 

Employee Profile

Seamlessly retrieve all employee data like first name, last name, unique ID, date of birth, work email, start date, termination data in case of former employees, marital data and employment type. 

Employee Organizational Structure

Hierarchical data for the employee, including information on the employee’s title and designation, department, manager details, subordinates or those who report to the employee, etc. 

Employee Dependents

Details about the family members of the employees including children, spouse and parents. The information includes name, relation, date of birth and other specific data points which can be useful when you are negotiating insurance and other benefits with third party companies. 

Employee Location 

Information on where the employee currently resides, specific address as well as the permanent address for the employee. 

Employee payroll

All kinds of details about the compensation for the employee, including gross pay, net pay, benefits and other earnings like commissions, bonuses, employee contributions to benefits, employer contributions, taxes and other deductions, reimbursements, etc. 

Wrapping up: TL:DR

Overall, if you observe it is very clear that increasingly, the payroll market is becoming more and more fragmented. Invariably, it is becoming extremely difficult for businesses using multiple payroll applications to normalize all data to facilitate understanding and exchange. To make sense of payroll APIs, you need to first acquaint yourself with the key payroll concepts like pay period, payroll run, compensation, in-hand pay, gross pay, reimbursements, benefits and deductions, etc. 

Once you understand these, you will agree that a payroll API can make the payment process seamless by helping in employee onboarding and payroll integration, management of reimbursements, administration of benefits and easy deductions, tax and net pay management, accounting and financial planning, among others. 

Increasingly, data from payroll APIs is also enabling other SaaS companies to power their operations, especially in the finance and fintech space. If you look closely, lending, insurance, portfolio management, etc. have become very streamlined, automated with a reduced reliance on manual process. At the same time, HR management has also become simplified, especially across performance management. Payroll data can help performance management companies help businesses identify the right incentive structure to motivate high performance. 

However, with increasing fragmentation, a unified payroll API can help businesses easily extract salary information, data on benefits and deductions and records about how and when the employees have been paid along with tax related information from a single source. Thus, if  you are adopting payroll API, look out for data normalization and data management for maximum business effectiveness. 

In this article we will learn about Merge API, a unified API solution to help developers build native integrations with multiple 3rd party end systems in one go using the 1:many connectors provided by Merge. 

We will also learn about what happens post integration - how data syncs happen on Merge API predominantly via a pull based model where Merge stores a copy of the end customer data in their servers, which could lead to end customer anxiety around security and compliance. 

Finally, we will talk about how Knit API is solving for this by working on a push based model which does not require any customer data storage - helping you reduce friction with your customers and alleviate their concerns on how their data is being handled.

Let’s dive in.

‍

What are unified APIs?

Essentially, a unified is a 1:Many API which helps developers go-live with multiple integrations within a category of SaaS with a one time effort of integrating with the unified API provided by the platform. For example, let's say an Employee Benefits platform wishes to integrate with multiple HRMS systems which its existing or potential customers use. In the absence of a unified API, the developers at the benefits platform will have to read API documentation of each HRMS, understand its data model and build the connectors 1:1. This wastes massive dev effort on a repetitive task which essentially serves the same basic purpose of syncing employee data from the customers HRMS to the benefits platform. Unified APIs save all of this effort by normalizing the data models of all the HRMS tools out there in to one common data model so the developers at the benefits platform have to work with just one connector rather than building a connector for each different HRMS tool in a 1:1 manner.

Other than building the integrations faster, unified APIs also help you maintain them in a low effort way by providing DIY integration management dashboards which your front line customer success teams can use to diagnose and fix any issues with live integrations so that your engineering team does not need to get involved every time there is a break or question around data syncs from your customers.

If you are wondering whether a unified API is a right solution for you or not, read this

Now, let us look at the components of a unified API solution.

‍

Key components of a unified API solution

Any unified API solution has four basic components - 

1. The auth component 

Users of your APP use the auth component, embedded in your APP, to authenticate and authorize access to their enterprise app to your SaaS application.

‍

2. 1:Many Connectors 

1:many connectors are simply put, a common data model which abstracts the data models of all the existing applications in a category of apps so that your engineering team can work with just the one connector provided by the unified API platform rather than individually integrating with all the connectors within that category of apps.  This saves massive time as your dev team does not need to understand the nuances of each and instead build your product logic on the common data model of the unified API provider.

‍

3. Integration Management 

Often the most neglected piece when teams build integrations in-house, integration management dashboards are one of the key value propositions of Unified API platforms since they help your frontline teams diagnose and fix any integration or sync issues without having to involve the engineering team each time. Think about the massive amount of time it can save in maintaining the integrations which are already built and live.

‍

4. Data Syncs

This is probably the core of the product - getting data in from the source app to your app and writing back from your app to the source is why we build integrations. Because this is important, we will talk about this in more detail below, and along the way of understanding Merge's data sync model.

‍

Data syncs via unified APIs

To understand how data syncs happen via unified APIs, we first need to understand that there are two parts to the process -

1. Data syncs between the source app and the unified API provider

2. Data syncs between the unified API provider and your app

‍

Data syncs between the source app and the unified API provider

The first part of the data sync is to read data from the source APP and do something. Now, here again, there are two phases:

• The initial data sync
• Delta syncs thereafter

The initial data sync happens when your app’s user has authenticated and authorized the unified API platform to access data from the source app for the first time. This is when Merge API accesses and stores a copy of the data in its own database. This is the copy of the data that Merge API uses to serve your app, i.e., the consumer app.

Post the initial syncs, the delta syncs come into the picture. The purpose of the delta syncs is to inform the consumer app of any changes in the data, for example title, manager, or location changes for any employee if you are syncing with a source HRMS system.

Now here, depending on the source system, delta syncs could be handled via webhooks OR by periodic polling of the source app. 

• When the source app supports Webhooks, like Rippling, it dispatches any delta events to Merge, which then changes its copy to reflect the new information available. 
• When the source app does not support Webhooks, like Success Factors, Merge has to again read the entire data from the source app and create a fresh copy of the data by polling the source system at pre-set frequencies. Depending on the plan you have, these sync frequencies could be every 24 hours or more frequent.

The thing to note is that in both scenarios, whether or not the source app supports Webhooks, Merge API serves the consumer app via its stored copy of the data.

‍

Concerns with a data storage first model for data syncs

A data storage based model brings with it multiple challenges. First and foremost the end customers who are authorizing your app to access their data via Merge API might not be comfortable with a third party having a copy of their data stored somewhere. Even when Merge API is SOC2 compliant, as ex-users of Merge APIs HRMS integrations for our HRTech venture, we had a segment of customers who had concerns about the handling of the data, employee data being PII, and there were also concerns about where the data is being stored (in some cases outside the customers geography).

This added unnecessary friction between us and our customers, requiring additional infosec questions and paperwork which delayed deal closures or in some cases led to deals not closing at all.

‍

Data syncs between the unified API provider and your app 

Now that the unified API provider has the data, your app must consume the data for your business logic to work. There are two main philosophies or approaches here - pull vs push.

‍

The pull model

‍

In a pull model, your servers are busy making calls to the data providers like HRIS, Payroll systems etc. to get data. In order to do so, you will need to create a polling infra.

If you're doing so for 10-15 batch jobs, perhaps it is manageable. But imagine doing this for hundreds, even thousands, of jobs. The problem gets harder. Further, if there is no new data to report, you just wasted your compute resources on an empty call.

‍

The push model

‍

Now compare this with the push model. Typically, you will be required to subscribe to certain events by registering a webhook. When the event happens, the data providers would notify you with appropriate payload on the registered destination URL. 

You don't have to manage any polling infra, nor would you waste compute resources on inconsequential calls. With event driven microservices architectures on the rise, the push model is definitely easier to work with and scale vs a pull model.

‍

Which approach does Merge API use? Pull or Push?

Here, the Merge API relies heavily on a pull-based approach (though it does provide delta webhooks, which we will talk about below). Let’s look at the three options Merge API provides to consumer apps-

‍

1. Periodic Syncs

Here, your app is expected to periodically poll the Merge copy of the data, such as every 24 hours. What this means is that you will have to build and maintain a polling infrastructure at your end for each connected customer. This is ok if you have a small number of customers, but quickly gets difficult to maintain if you have lots of connected customers.

‍

2. Ad-hoc Syncs 

If your app wants to sync data frequently, Merge API provides an option for you to write sync functions which can pull only data which has changed since last sync using its modified_after timestamp. While this reduces the data load, it still requires the polling infrastructure we talked about in point 1.

‍

3. Webhooks

Merge’s webhooks are again of two types - sync notifications and changed data webhooks. 

Sync notification events are simply notifications to your app that something in the data has changed and expects you to start the ad-hoc sync once you receive the notification - so essentially pull. On the other hand, while it does offer the changed data webhooks, it does not guarantee scale and data delivery via these webhooks. 

From Merge’s doc:

• Merge offers webhooks that deliver updated data when individual data instances are updated, but depending on the amount of user data, this will not scale well. 
• Make sure to implement polling and don't rely entirely on notification webhooks. They can fail for a variety of reasons (such as downtime on your end or failed processing). Merge does attempt to redeliver multiple times using exponential backoff, but we still recommend calling your sync functions on a periodic cadence of around once every 24 hours.

So you see the problem? You will not be able to work around the need for building and maintaining a separate polling infrastructure. 

‍

Knit’s approach to data syncs

While everyone talks about security, at Knit, we actually have walked the talk by embedding security in our platform architecture. 

We do NOT store a copy of the source data with us. And we have built a completely events driven architecture from the ground up, so we work only with Webhooks and deliver both the initial and delta syncs to your app via events.

So you have less compliance and convincing to do with your customers, and do not have to  waste engineering resources on polling while at the same time get guaranteed scalability and delivery irrespective of the data load.

Another advantage of a true events driven architecture is that it supports real time use cases (where the source APP supports real time webhook pushes) which a polling based architecture does not.

While we will soon be covering our architecture that guarantees security, scale and resilience for event driven stream processing in more detail in a follow up post, you could read more about the basics of how Knit API functions here: Knit API Documentation

‍

Other advantages of Knit API over Merge API

1. Auth component

Knit’s auth component offers a lot of flexibility in terms of design and styling vs what Merge API offers. 

It is a Javascript SDK which is far more customizable as compared to iframe which is Merge’s choice for the frontend auth component. 

So if you want to make sure that the auth component which your customers are interacting with, looks and feels similar to your own APP, Knit API might just be the right solution for you.

‍

2. Integration Management

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. 

While Merge also offers customer success dashboards, they are not as deep, so your frontline folks will have to reach out to your engineering teams more frequently. And we all know how much engineering teams enjoy maintaining integrations and going through logs to check for data sync issues rather than building cool new core product features ;)

‍

Final Thoughts

Knit is the only unified API solution which does not store customer data, and offers a scalable, and reliable push driven data sync model for large data loads. 

This has several benefits:

• Better security: Since Knit does not store any customer data, you and your customers can be confident about data security and you can close deals much faster.
• Better developer experience: Since you do not need to maintain any polling infrastructure for Knit due to its events driven architecture, your developers have lesser issues maintaining it.
• Better scalability & reliability: Even with a webhook first model, Knit guarantees data delivery and scalability irrespective of the amount of data being synced between the source and destination apps. We offer a 99.99 SLA and aiming for 99.9999 soon.

Curious to learn more about Knit? Get started today

‍

We’ve been hard at work these past few weeks adding a bunch of new integrations and major feature improvements to make Knit even more valuable to you. We are super excited to share them with you and hope that you enjoy them as much as we do:

1. We launched the 6th unified API category: Assessment APIs
‍

Multiple integrations. Minimal effort. One API

Connect with multiple ATS, HRIS, Accounting, CRM and Chat tools using only the Knit API

Get started

Get started

‍

Our Assessment unified API enables organizations to personalize candidate experience even further. 

With Assessment, you can start an assessment process for a candidate, extract assessment lists, send assessment invites and fetch assessment results when the process is completed. We released the category with two most popular Assessment APIs: Perspect AI and The Predictive Index. Stay tuned as we add more apps to this category. 

Learn more

‍

2. Perform more operations with Knit’s new Write APIs

Our HRIS and ATS unified APIs now include more Write capabilities. Here’s what you can do with our new Write APIs:

• Update/ create employees (HRIS)
• Add attachments to an application (ATS)
• Add tag to a candidate (ATS)
• Create a candidate note (ATS)
• Reject an application (ATS)

Learn more

‍

3. Enhance user experience with advanced customization on the UI Auth component

Along with customizing the text, font and branding on the auth/intro screen, you can now enable skipping the admin auth screen altogether — the user can directly go to the catalog and from there, to the credentials screen. 

Learn more

‍

4. More integrations added for you

Our integration catalog just got expanded. We added 7 new integrations and a new unified API category in July. 

• HRIS: HiBob, ADP Workforce Now
• ATS: ADP Workforce Now, Sage, Breezy HR
• Assessment: The Predictive Index, Perspect AI

If you’ve got any special integration request, please reach out to us. We will be happy to help.

‍

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.

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

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?

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

Knit has recently rolled out one of its most anticipated features: User Management.

With the User Management feature you can now add multiple users with different capabilities to your Knit account based on their roles. 

In this article, we will discuss how to get started with the User Management feature and maximize its benefits.

What is User Management?

The User Management feature allows you to add multiple users to your organization’s Knit account and also assign them roles and permissions . It means multiple users can login and have access to your organization’s integrated accounts and various other features as a part of integration management. 

Knit currently serves 3 categories of possible roles for any organization. 

1. Admin

Admins have full access to all the features in the dashboard. They are in a way the primary users who have the right to add/edit/remove new users.  

2. Member

Members have access to only manage integrations and webhooks. Unlike Admins, they cannot add/update users or make changes to the organization’s account with Knit.

3. Billing Contact

Billing contact has access to only billing related options, like editing payment details, selecting plans etc.

For more information on setting up the User Management feature, take a look at this video. 

How to access the User Management page

‍

When you\ sign up to your Knit Dashboard, you will be logged in as an administrator of the organization you have just created. 

You can then access user management by going to the settings page.

‍

In the settings page you will have access to user management, among other settings.

‍

‍

The User Management screen shows you all the users assigned to your organization, their emails, permissions and also gives you the option to see and edit their roles.

To invite a new user to your org, click on the Add User button on top right.

Here, you can enter the email ID of the person you’d like to invite to join your organization. You can also set their role. Invited users will receive an invite link on their respective email ID.

For detailed information about dashboard access for each role, be sure to check out the User Roles tab.

You can also edit the roles for a user, and resend the invitation to invited users.

What if we have already created multiple separate accounts and want to combine them?

If you have already created multiple separate accounts (by signing up separately with your individual email IDs), we can help you combine them into a single account. 

In the process, we will also combine your integrated accounts, and organizations from multiple accounts.

However, it would not be possible to transfer pre-existing syncs, logs and issues. As a result, once the integrated accounts are transferred, you’ll have to restart the sync for them.

Note: If you have created multiple accounts for testing and production, we recommend that you do not to merge them as the User Management feature does not provide for segregation of environments. 

Thus, it is best to have a separate account for production and for testing in that case.

Let’s get started

Please reach out to kunal@getknit.dev with the list of email addresses (along with their respective roles) that you would like to combine and we’d be happy to help you through it! Get in touch

March had been quite eventful for Knit. We made some interesting changes in its product features, launched a new API category and 10+ new apps to our integration portfolio. Here’s a quick summary:

New Unified API Category: ATS Integrations

We are excited to announce our new Unified API category: Applicant Tracking Systems with two sets of ATS data models: applications and jobs. Our ATS APIs include both read and write functionalities. 

ATS is now available on Knit with 3 integrations: Lever and Greenhouse.

Learn more

‍

New Feature: Interactive Messages

Knit now offers interactive messages for Slack and Teams integrations. Unlike regular messages, interactive messages have an interactive component such as a button or dropdown. Currently, we are only offering support for one interactive component: Buttons.

Learn more

‍

New Launch: Slack and Teams Bot

Our communication APIs just got stronger: you can now create your own bot on Slack and MS Teams with Knit to send messages or interact with users. 

See docs

‍

New Dashboard Menu: Logs

Now auditing the status of your integrations is easier with our new Logs menu. You can check the health of your webhooks and API calls on a single page. You can sort the logs by time (last 24 hours, 30 days, 60 days, 6 months, and 1 year) or you can sort them by organizations or both. 

• The webhooks log contains details about webhook URL and status, app/ integration name, organization name along with date and time stamp for each webhook.
• Whereas, the API call log provides information about method, URL, app/ integration name, organization and a date and time stamp for each API call made.

‍

New Feature: Custom Fields

Our Custom Fields feature allows more flexibility to your users by letting them map specific fields from the apps they use into the common data models provided by Knit for a complete unified experience.

‍

New HRIS Integrations

We are excited to have expanded our HRIS integration catalog further in March by adding the following apps: Gusto, Rippling, Oracle HCM, Zenefits, Namely, Freshteam and SAP SuccessFactors.

Please let us know. We will make sure you are on the top of our priority list 😀 Feel free to contact us here

If you want to get your hands on our latest features, sign up for your free trial here

That’s all for this month. We have several new features and a host of new integrations to be launched in April. Stay tuned :)

We are elated to announce that we recently launched our most anticipated update: a brand new Getting Started flow! 

Let’s dive in.

What is Getting Started?

The Getting Started journey consists of 4 comprehensive yet easy to follow steps to help you set up Knit and start using our powerful syncs and unified APIs quickly! 

In this guide, we will walk you through everything from registering webhooks and setting up the UI component to finally making API calls and syncing data.

Step 1: Select Category

First, you’ll have to select a category of integrations that you’re interested in. This would enable you to walk through that category’s events and APIs and get started with it immediately. 

Don’t worry, if you’re interested in multiple categories, once you’ve completed all the steps for one category, you can come back and select another one.

Step 2: Register webhook

If the category supports data sync, you’ll be prompted to register a webhook for it. If not, then you can skip this step and move directly to the next!

But before we get into the details of this step, let’s first discuss what a webhook is. Simply put, we use webhooks to send you information. So, a webhook URL is like an address wherein you tell us where to find you in case we have some data for you. So, before we begin with the rest of the stuff, you’ve got to tell us where to find you! 

In this step, you’ll be able to register the webhook wherein we’ll send you sync events. While registering the URL, you can also see the different kinds of events that we’ll be sending in different circumstances and test your webhook against them. As Knit works on a completely webhooks-first design, no polling is required for data sync.

Once you’ve successfully registered the webhook, you can then enable the category to start integrating with apps. 

Step 3: Setup Knit UI

In this step, you should get your API key, and be able to integrate with an app from the frontend using either of the following two methods. 

1) By embedding Knit UI

Embedding the Knit UI component lets your users make native integrations from within your app. In this step, we help you get your API Key, set up your backend to make auth sessions, and ultimately embed the Knit UI SDK in your frontend. We have comprehensive code snippets for all the popular frameworks in JavaScript TypeScript for you to refer to. 

‍

2) Use the Magic Link

If you don’t want to embed the UI component in the frontend, or want your users to get started immediately, you can use the Magic Link feature to integrate with an app in the browser. 

Just fill the form with the required information like your user’s organization ID, name, user email address doing the integration, and the category they wish to integrate with and you’ll get a link with which you can get started in your browser immediately. 

Don’t worry, if you wish to come back and embed the UI component later on, you can find the documentation in the ‘Resources’ section.

Step 4: Fetch data and make API calls

That’s it! It’s time to start syncing data and making API calls and take advantage of Knit unified APIs and its data models. Depending on the category you’re interested in, you will find detailed information.

If the category supports syncs, like HRIS, ATS, CRM and Accounting, you’ll find the list of data models and syncs we support for that category. You can choose the data models you want to subscribe to while doing a data sync. Once you have finalised your selection, you can start syncing your data. 

Once you integrate with an app (if you haven’t done so already), we will immediately start syncing the data of the subscribed data models and sending events to the webhook you had registered in step two. Once a sync has started, you can restart/pause the sync or even change the subscribed data models from the Integrated accounts page. 

You can read more about syncs here: How Syncs work

Along with the data models, you’ll also find the documentation references for the APIs supported by the category.

We made it! Now you know everything there is to know about getting started with Knit and how to start integrating applications, syncing data and making API calls. 

Be sure to check out our documentation here. You can find all the data models, API reference, and detailed guides about each feature in there!

We’re really excited for you to get started with Knit, and can’t wait to see the amazing things you’ll achieve with it! 🚀

‍

August was eventful for us. We added some cool new features, updated some old ones and integrated with more apps. Here's a sneak peek at what's new at Knit:

1. Go beyond the common data model

Common data models can sometimes be limiting. Whenever you are looking to get specific data that is not included in Knit’s common data model, you can use our new feature: Passthrough Requests.

It enables you to make API calls directly to any of the apps supported by Knit. These API calls are directly sent to the integration’s API. And the best part? All the authentication and authorization processes are taken care of by Knit.

Learn more  

2. Fetch Raw Values of source data

Along with fetching data beyond common data models, now, after each sync, you will also get data in its source format i.e. data in each integration’s specific API format instead of Knit’s unified format. 

If your integrated apps allow setting custom values for specific types of data, this feature will help you capture that raw data value.

Learn more

3. Program your ad-hoc syncs

We have now added a new API to Knit that enables you to start ad-hoc data syncs programmatically instead of having to do it manually every time.

If you have a lot of integrated accounts, this simple automation will significantly reduce your integration maintenance time.

See Docs

4. New HRIS integrations

We have recently added two new HRIS apps to our catalog: UKG Pro and Sage HRIS. With that, our HR integration portfolio (HRIS, Payroll, Directory and ATS) is now 30 apps strong.

Check full catalog

Have any specific integration requests? Please reach out to us here. We would be happy to  prioritize your needs. 

5. Get advanced employee data

We have updated our employee data models for HRIS with new additions. Now, for each employee, you can fetch identification data along with profile pictures and complete bank account details (e.g. IFSC and branch code etc.)

See more

What’s Next?

The Knit team is working super hard to bring you some cool new features to further streamline your integration processes. Data filters and multiple user management  are the two of the much awaited updates. Stay tuned for our next email for more info on this.

Meanwhile, got any query or request about Knit? Please feel free to contact us

‍

Knit has been onto some big things lately and it's a pleasure to share it with the world.

1. We launched on Product Hunt 🚀

Firstly, we successfully launched on Product Hunt a week ago and became the #1 DevTool of the week. The love and support we received from our current users and the Product Hunt community has blown us away. We are grateful beyond measure 🙏.If you missed out on the big launch, here’s a sneak peek

‍

2. A brand new getting started flow

We have built a complete Get Started flow to our app to help you make the most of Knit. If you have any doubt, you can read our Getting Started guide here.

(P.S. We are updating the current flow to improve your user experience further. Stay tuned!)

‍

3. Launched Magic Link

Magic Link makes setting up Knit API easier. If you don’t want to embed the UI component in the frontend, or want your users to get started immediately, you can use the Magic Link feature to integrate with an app in the browser. Read more

‍

4. Expanded integrations catalog

We added 7 new ATS integrations to Knit’s portfolio: Workday, SAP SuccessFactors, Darwinbox, Workable, Smart Recruiters, Freshteam and Oracle HCM. We also added Workday to the HRIS category. Check our full integrations catalog here

‍

5. Playground Apps in Sandbox

Playground apps help you embed Knit in your code base quickly and confidently. Playground HRIS and ATS apps are dummy apps that help mimic Knit data models for HRIS and ATS syncs. These apps are a great way to start playing/setting up Knit syncs in case one doesn’t have access to any real app.

‍

What’s next?

We are scaling our product features and expanding our integrations catalog super fast 🚀 

We will soon be launching our support for the CRM category with Salesforce & Hubspot and Accounting category with Quickbooks, Xero and Zohobooks.

Stay tuned for more updates!

‍