Knit is #1 product of the week in the developer tools category on Product Hunt!

Build vs Buy: The Best Approach to SaaS Integrations

Should you Build integrations in-house? Or Buy a third-party solution? Read this article to find the best integration strategy that suits your business roadmap

Any SaaS company on an average uses 350+ integrations. While SaaS unicorns use 2000+ integrations, a new startup also uses 15+ integrations on average. What is common to all SaaS companies is the increasing number of integrations they are using. To facilitate a faster time to market and increased data/ information exchange, quality SaaS integrations have become a go-to for almost all businesses. 

However, when it comes to building, deploying and maintaining SaaS integrations, companies tend to get overwhelmed by the costs involved, engineering expertise needed, security concerns, among others. 

Invariably, there are one of two paths that businesses can explore, either building integrations in house or buying them/ outsourcing the process to a third-party platform. In this article, we will uncover:

  • Top two approaches to SaaS integration
  • Build vs Buy for SaaS integrations: Key considerations
  • Which one to choose
  • Unified API as a solution for SaaS integrations
If you are interested to learn more about the types, trends, and forecast of SaaS integrations, download our State of SaaS integration: 2023 report

Which integration stage are you at?

Before we discuss the pros and cons of the two parallel ways of achieving integration success, it is important to understand which integration stage you are at. Put simply, each integration stage has its own requirements and challenges and, thus, your integration approach should focus on addressing the same. 

Stage I: Getting started

It is the first stage, you are in the launch phase where you are all set to go live with your product. However, currently, you don’t have any integration capabilities. While your product might be ripe for integration with other applications, the process to facilitate the same is not yet implemented. 

This might lead to a situation where your customers are apprehensive about trying your product as they are unable to integrate their data, and may even see it as underdeveloped and not market-ready. 

At this stage, your integration requirements are:

  • Low cost integration deployment and maintenance
  • Prevention of diversion of focus from core product enhancement for your internal engineering team
  • Ability to quickly and easily integrate with different applications and systems to drive adoption of your product

Stage II: Scale up

In the second stage, your product has been in the market for sometime and you have managed to deploy some basic integrations that you have built in-house. 

Now your goal is to scale your product, ensure deeper market penetration and customer acquisition. However, this comes with an increased customer demand of deploying more complex integrations as well as the need to facilitate greater volume of data exchange. Without more integrations, you will find yourself unable to scale your business operations. 

For scale up, your integration requirements are:

  • Facilitating new customer acquisition and preventing business revenue loss with streamlined integration experience 
  • Accelerated integration addition and implementation to keep pace with customer demand
  • Real-time integration support for customers queries to prevent any delays 
  • Ability to maintain and manage integrations, error handling, troubleshooting etc. for a seamless experience 

Stage III: Sustain and grow

In the third stage, you have established yourself as a credible SaaS company in your industry, who provides a large suite of integrations for your customers. 

Your goal now is to sustain and grow your position in the market by adding sophisticated integrations that can drive digital transformation and even lead to monetization opportunities for your business. 

This stage has its own unique integration requirements, including:

  • Comprehensive integration support without additional costs for maintenance and management
  • Increase in integration coverage across different APIs and new-age integrations
  • Monetization of integrations by offering them as exclusive features at a premium to add business value for customers
  • Preventing costs of adding incremental updates and API changes for smooth functioning
Overall, across all the three stages, while the requirements change, the expectations from integrations revolve around being cost effective, easy maintenance and management without draining resources, supporting the large integration ecosystem and ultimately creating a seamless customer experience. 

Therefore, your integration strategy must focus on customer success and there are two major ways you can go about the same. 

Two modes of integration: Build vs Buy

Irrespective of which integration stage you are at, there are two approaches that you can consider to traverse the integration ecosystem. Put simply, you can either build integrations in-house or you can partner with an external or third party player and buy integrations. 

  • Building integrations in-house will give you end-to-end control and the option to customize each functionality to give a very native feeling. This is ideal if you have to add only a couple of integrations, which your engineering team can manage along with core product development. 
  • However, buying or outsourcing integration development and management enables you to scale at speed and makes the process more cost efficient, resource lite and faster. Companies that prefer buying integrations believe that their developers should solely focus on product development and the supplementary efforts for integrations should be outsourced. 

The integration development process

If you are using SaaS integrations, you are likely to rely on APIs to facilitate data connectivity. This is the case whether you build it in-house or outsource the process. From a macro lens, it looks like a streamlined process where you connect different APIs, and integrations are done. However, on a granular level, the process is a little more complex, time consuming and resource intensive. 

Here is a snapshot of what goes into the API based integration development:

1. Get publicly available APIs or build them in-house 

The first step is to gauge whether or not the full version of the API is publicly available for use. If it is, you are safe, if not, you have to put in manual effort and engineering time to build and deploy a mechanism like a CSV importer for file transfer, which may be prone to security risks and errors. 

2. Access to comprehensive documentation

Next, it is important to go through the documentation that comes along with the API to ensure that all aspects required for integration are taken care of. In case the API data importer has been built in-house, documentation for the same also needs to be prepared. 

3. API alignment with product use case

Furthermore, it is vital to ensure that the API available aligns and complies with the use case required for your product. In case it doesn’t, there needs to be a conversation and deliberation with the native application company to sail through. 

4. Legal/ compliance requirements for data access

Finally, you need to ensure that all legal or compliance requirements are adhered to revolving around data access and transfer from their API, through some partnership or something along those lines. 

Should you build integrations in-house? 

Now that you have a basic understanding of the requirements of the integration development process, answer the following questions to gauge what makes more sense, building integrations in-house or outsourcing them. 

#Q1. How many integrations do you have?

Start by taking a stock of how many integrations you have or need as a part of your product roadmap. Considering that you will have varied customers with diverse needs and requirements, you will need multiple integrations, even within the same software category. 

For instance, some of your customers might use Salesforce CRM and others might use Zoho. However, as a SaaS provider, you need to offer integrations with both. And, this is just the top of the iceberg. Within each category, there can be 1000s of integrations like in HRIS with several vertical categories to  address. 

Thus, you need to gauge if it is feasible for you to build so many integrations in-house without compromising on other priorities.

#Q2. Do you have domain expertise with the concerned integrations?

Second, it is quite possible that your engineering team and others have expertise only in your area of operation and not specific experience or comprehensive knowledge about the integrations that you seek. 

For instance, if you are working with HRIS integrations, chances are your team members don’t understand or are very comfortable with the terminologies or the language of data models being used. 

With limited knowledge, data mapping across fields for exchange can become difficult and as integrations become more sophisticated, the overall process will get more complex. 

#Q3. When do you want to roll out the integrations?

Next, you need to understand what is your timeline for rolling out your product with the required integrations. 

A single integration can take up to 3 months to build from planning, design and deployment to implementation and testing. Thus, you need to ask yourself if this duration sits well with your go-to-market timeline. 

At the same time, you need to consider the impact any such delay due to integration might have on your market penetration and customer acquisition vis-a-vis your competitors. Therefore, building integrations in-house which are too time consuming can also add an opportunity cost. 

#Q4. Have you calculated the costs associated?

Undoubtedly, one is the opportunity cost that we have discussed above, which might result from any delays in going live due to delay in building integrations. However, there are direct costs of building and maintaining the integrations. 

Based on calculations of time taken for building integrations and factoring in the compensation for developers, each integration can cost on an average 10K USD. At the same time, you lose out on the productivity that your engineering time might have spent on accelerating your product roadmap timeline. 

It is important to do a cost benefit analysis as to how much of business value in terms of your core product you might need to give up in order to build integrations. 

#Q5. Do you have enough resources?

This is a classic dilemma that you might face. If you are building integrations in-house, you need to have enough engineering resources to work on building and maintaining the integrations. Invariably, overall, there has been a shortage of software development resources as reported by many companies. Even if you have enough resources, do you think diverting them to build integrations is the most efficient use of their time and effort? 

  • On one hand, this could result in a delay or hamper your product core functionalities. 
  • On the other hand, your developers might not even be interested in working on something that doesn’t contribute to the core product. 

Therefore, you are likely to face a resource challenge and you must deploy them in the most productive manner. 

#Q6. Have you considered security and authentication?

A key parameter for API integration is authentication to ensure that there is no unauthorized access of data or information via the API. If you build integrations in-house, managing data authorization/ authentication and compliance can be a complicated process. 

While generally, integrations are formed on OAuth with access tokens for data exchange. However, other measures like BasicAuth with encoded username, OAuth 2.0 with access using third-party platforms and private API keys are also being used. 

At the same time, even one SaaS application can require multiple access tokens across the platform, resulting in a plethora of access tokens for multiple applications. You need to gauge if your teams and platforms are ready to manage such authentication measures. 

#Q7: What about data normalization and mapping?

Once your integration is ready, the next stage of data exchange comes to life. While deciding whether to build integrations or buy them, you need to think about how you will standardize or normalize the data you receive from various applications to make sure everyone understands it. For instance, some applications might have one syntax for employee ID, while others might use it as emp ID. There are also factors like filling missing fields or understanding the underlying meaning of data.

Normalizing data between two applications in itself can be daunting, and when several applications are at play, it becomes more challenging. 

#Q8. Have you considered the management and maintenance required?

An integral role that you take up when building integrations in-house is their management and maintenance which has several layers. 

  • First, you need to constantly refresh the data to ensure that any fresh data in one application is automatically synced with the other one by refreshing the cache. 
  • Second, systems or APIs might fail, leading to errors in functioning. You need to be prepared for handling such errors and troubleshooting challenges to ensure that the business continuity of your customers is not disrupted. This might require unnecessary bandwidth deployment in addressing minor technical issues with the teams of applications from where you have received your API. 
  • Third, the API you are using might not have the customization capability needed for your use case, which might take up considerable bandwidth.
  • Fourth, the APIs are updated often and these changes need to be tracked and fixed before the customers realize. 

Build vs Buy: Which way to go?

Building integrations in-house can be cost intensive and complicated, whereas, buying or outsourcing integrations is resource-lite and a scalable model. To help you make the right choice, we have created a list of conditions and the best way to go for each one of them.

build vs buy: best approach for SaaS integration

Unified API to outsource integrations

Undoubtedly, there are several ways you can adopt to outsource or buy integrations from third party partners. However, the best outsourcing can be achieved with a unified API. Essentially, a unified API adds an additional abstraction layer to your APIs which enables data connectivity with authentication and authorization. 

Here are some of the top benefits that you can realize if you outsource your integration development and management with a unified API. 

Faster time to market and scale

With a unified API, businesses can bring their time-to-market to a few weeks from a few months. 

  • On one hand, this helps them reach the market before their competition, giving an edge for market penetration. 
  • On the other hand, a unified API also allows them to add more integrations and scale keeping pace with customer demands. 

When it comes to the overall picture, a unified API can help businesses save years in engineering time with all integrations that they use. At the same time, since the in-house engineering teams can focus on the core product, they can also launch other functionalities faster. 

Greater coverage

A unified API also provides you with greater coverage when it comes to APIs. 

If you look at the API landscape, there are several types and API endpoints. A unified API will ensure that all API types and endpoints are aggregated into a single platform. 

For instance, it can help you integrate all CRM platforms like Salesforce, Zoho etc. with a single endpoint. Thus, you can cover the major integration requirements without the need to manually facilitate point-to-point integration for all.  

Low costs and operational efficiency

Undoubtedly, a unified API brings down the cost of building integrations. 

  • First, the hard costs associated with building integrations like developer time and storage costs are significantly reduced. 
  • Second, soft costs like opportunity costs due to delays in market entry can also be eliminated. 
  • Third, a unified API also takes care of maintenance with error handling, troubleshooting, managing expired tokens, fixing API source schema change etc. For instance, Knit Unified API offers a dedicated dashboard with RCA and resolution as well as proactively fixing them for its users as and when necessary. This adds to the operational efficiency for your developers, preventing unnecessary diversion of focus for them. 

Opportunity to monetize

A unified API can help you provide unparalleled features to your customers which blend beautifully with your core functionalities. You can even automate certain tasks and actions for your customers. This  leads to a significant impact for your customers as well in terms of cost and time saving. 

In such a situation, chances are very high that your customers will be happy to pay a premium for such an experience, leading to a monetization opportunity which you might have not been able to achieve if you build integrations in-house, considering the volume you need to address for monetization. 

Single API knowledge required

Finally, a unified API ensures that your engineering teams only need to learn about the nuances, rules and architecture of one API as opposed to thousands in case of in-house integration development. This significantly reduces the learning hours that your developers can invest in value oriented tasks and learning. 

Wrapping up: TL:DR

As we draw the discussion to a close, it is evident that building and maintenance of integrations can be a complex, expensive and time consuming process. Businesses have two ways to achieve their integrations, either build them in-house or outsource them and buy them from a third party partner. 

While building integrations in-house keeps end to end control with the businesses, it can be difficult to sustain and maintain in the longer run. 

Thus, buying or outsourcing integrations makes more sense because it is:

Cost and time effective, facilitating faster time-to-market at a lower cost 

  • Resource-lite and doesn’t add burden to developers, preventing diversion of focus away from product roadmap
  • Has the potential to add multiple integrations at once, leading to higher coverage
  • Takes care of authentication, authorization and security
  • Ensures access to all APIs, irrespective of whether they are publicly available or not
  • Takes away the time and effort related to ongoing integration maintenance.
  • A unified API is a smart solution and a competent alternative to building integrations in-house for businesses in different stages of the integration cycle. You integrate once with a single API and get access to hundreds of apps within a single category. 

Looking to outsource you integration efforts? Check out what the Knit Unified API has to offer or get API keys today.

Sudeshna Roy

Head of Content, Knit

Decoding product and generating users with valuable content

Latest Blogs

Browse all Blogs
May 26, 2024

Top 5 Finch Alternatives


Top 5 Alternatives to tryfinch


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: 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 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, 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


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. 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.

API Directory
Apr 9, 2024

A Guide toIntegrating with Freshteams API


Freshteam API Directory

A cloud based HR software, Freshteam enables organizations with managing employee details, recruitment, on-boarding, time-off, off-boarding, and organization details, among other aspects of their HR processes and practices. With Freshteam API integration, organizations can seamlessly synchronize data between their application and Freshteam to ensure real time updation of employee information across both platforms. It helps capture any changes in employee status, designation, HR policies, etc. across different applications a business uses. 

Freshteam API Authentication, Filtering, Rate Limits

To ensure utmost security and prevent unauthorized access, Freshteam API uses Oauth2.0 for authentication and authorization. Developers can use the Freshteam UI to make calls to the Freshteam authentication server to obtain an access token. This access token can be used to make valid API calls thereon. The access token identifies the requester and the requester’s permission. In the Freshteam domain, the access token is present under Your API Key, which can be copied and used to make API calls. 

Rate limits i.e. the number of API calls that can be made in a minute for Fresteam API are determined by the plan selected by the organization. The rate limit variation for each plan is dependent on the number of subscribed employees for the organization. The trial account has a limit of 10 API calls per minute, which goes on to as high as (100, 2 * number of subscribed employees) API calls per minute for the enterprise plan. Developers or admins can also keep a track of the API calls to understand their usage patterns via:

  • X-ratelimit-total: Permissible number of API calls in a minute.
  • X-ratelimit-remaining: Number of API calls remaining.
  • X-ratelimit-used-currentrequest: Number of API calls consumed by the API request that obtained the response.

There are several endpoints in Freshteam API which retrieve bulk data, especially the ones which are required to List a certain object. In such a case, developers can use pagination parameters to filter data and limit the responses for a streamlined understanding. Developers can select the page value (from which page number they want responses), as well as the number of responses required for each page (default is set at 50). They can also sort the values as ascending or descending or select some other attribute for sorting as well. 

Freshteam API Objects, Data Models & Endpoints


  • List all employees: GET /employees
  • Create an employee: POST /employees
  • Retrieve employee information: GET /employees/{id}
  • Update employee information: PUT /employees/{id}
  • List all employee fields: GET /employee_fields
  • Create a custom employee field: POST /employee_fields

Common attributes: id, created at, updated at, workstation number, date of birth, gender, address, communication address, designation, phone number, joining date, termination date, first name, last name, status, official email, personal email, employee type, team id, department id, reporting to id, time off, hire reason, marital status, etc. 


(Used to configure different geographical locations for an organization and associate employees to a branch)

  • List all branches: GET /branches

Common attributes: id, created at, updated at, name, street, state, country code, zip, time zone, currency, language, main office, date format

Departments & Sub-Departments

  • List all departments: GET /departments
  • List all sub-departments: GET /sub_departments

Business Units

  • List all business units: GET /business_units

Common attributes: id, created at, updated at, name, description


  • List all teams: GET /teams


  • List all levels: GET /levels


  • List all timeoffs: GET /time_offs
  • Create a timeoff request: POST /time_offs
  • List all timeoff types: GET /time_off_types
  • Retrieve timeoff information: GET /time_off_types/{id}
  • Cancel A Timeoff Request: PUT /time_off_types/{id}/ cancel
  • Approve A Timeoff Request: PUT /time_off_types/{id}/ approve

Common attributes: id, created at, updated at, start date, end date, status, leave units, leave type id, status comments, comments, attachment, applied by, approved by, rejected by, canceled by, notify to, description, add to calendar, canceled at, optional leave days, applicable for, auto approve, status


  • List all roles: GET /roles

Job Postings

  • List all job postings: GET /job_postings
  • Retrieve job posting information: GET /job_postings/{id}
  • List all job posting fields: GET /job_posting_fields
  • List all applicant fields: GET /job_postings/{id}/applicant_fields
  • Create an applicant: POST  /job_postings/{id}/applicants

Common attributes: id, created at, updated at, deleted, title, description, status, show_pursue_as_career, closing date, experience, remote, type, salary, branch, department, title, location, skills, requisitions, label, field type, position, candidate, candidate id, first name, last name, date of birth, mobile, phone number, source id, resume, cover letter, portfolio, skype id, content file name, url, gender, profile link, rejected at, archived at, on hold at, on hold till

Candidate Sources

  • List all candidate sources: GET /candidate_sources
  • Create a candidate source: POST /candidate_sources
  • List all candidate source categories: GET ​/candidate_source_categories

Common attributes: id, created at, updated at, deleted, label, default, leads count

User Functions

  • List all user functions: GET /user_functions

New Hires

  • Create a new hire: POST /new_hires
  • Retrieve new hire information: GET /new_hires/{id}
  • Update new hire information: PUT /new_hires/{id}

Common attributes: id, created at, updated at, deleted, first name, middle name, last name, official email, employee id, status, workstation number, designation, joining date, probation start date, probation end date, branch id, team id, department id, sub department id, termination date, termination reason, notice period, notice start date, notice end date, employee type, hired on, no show, no show reason, date of birth, marital status, gender, blood group, emergency contacts, social profiles, address, communication address, phone numbers, job codes, job exempt, scheduled weekly hours, retirement eligibility date, rehire eligibility, rehire status, confirmed, language, branch, team

Freshteam API Use Cases

  • Centralize HR operations with AI-powered virtual agents, self-service solutions and  seamless integration with MS Teams, Slack, and other applications
  • Automate internal processes with easy-to-configure workflows, leading to streamlined work and increased efficiency
  • Leverage 50+ job descriptions out of the box for use to accelerate hiring processes
  • Capture qualitative feedback about candidates along with better candidate relationships through built-in email and a manageable candidate database

Top customers

50,000+ companies from across 120+ countries use Freshteam to power their HR operations and streamline processes to make them efficient, robust and optimized. Here are some of the top customers that are leveraging Freshteam:

  • Gartner, Inc., an American technological research and consulting firm
  • OpeninApp, a smart link generator tool that ensures all social media links open in the apps they should
  • Dymocks Booksellers, an Australian-founded privately owned bookstore chain
  • Valley Medical Center, a 321-bed, acute care community hospital and clinic network
  • Kirat Plastics, a full-service custom plastic injection molding, metal pressing, fabrication, and assembly facility
  • Lot Squared Development, a Washington DC based design-build residential real estate developer 

Freshteam API FAQs

Here is a list of Freshteam API FAQs that developers must understand to make their integration journey more effective and robust:

  • How to use Freshteam Developer API? Answer
  • Where to find Freshteam API key, how to reset it and Scope of an API Key? Answer
  • What are the status and error messages that indicate the success or failure of an API request in Freshteam API? Answer
  • What are the common request header parameters used in requests to Freshteam APIs? Answer
  • What are the API methods that developers interact with for Freshteam API? Answer
  • What are models in Freshteam API? Answer

Common Integrations with Freshteam API 

Businesses, especially those engaged in the employee side of work, are increasingly seeking integration with Freshteam API to streamline data exchange between this HRIS platform and their application. Some of the top use cases and common integrations with Freshteam API include:

  • Recruitment companies which can use the write APIs to update candidate information into Freshteam once a client is hired to ensure the customer’s HRIS is up to date for all onboarding and future requirements
  • Payroll providers can leverage both read APIs to fetch employee information for payroll creation and disbursement, as well as write APIs, to push back data into customer’s Freshteam account to notify that salaries have been paid
  • Rewards and recognition companies which can use integration with Freshteam API to fetch information on employees to seamlessly manage their operations and help end customers build a culture of recognition.  

How to integrate with Freshteam API 

To kickstart the integration journey with Freshteam API, developers can go through this quick start guide. The first step is to create a developer account and join the Freshteam developer community. Next developers need to follow the installation instructions to install the API SDK. Following this it is important to get acquainted with the authorization and authentication protocols to access data and make API calls.  Learn about the terms of use for accessing or using the Freshteam developer portal and understand the different terminology used. For more support and information, businesses can scroll through the Freshteam support page and get answers to their queries. 

Get started with Freshteam API 

Companies that integrate with Freshteam API benefit from the seamless exchange of information between this HRIS platform and their application and have been able to explore multiple use cases for their end customers. However, manually building and maintaining integration with Freshteam API can be a daunting task for developers. Building the integration alone can take 4 weeks on an average and cost USD 10K (considering the cost of software developers, QA engineers, etc.). Further, the cost associated with maintaining the Freshteam API adds another burden on the bottom line, while diverting resources away from core product functionalities and enhancements. And, this is for a single HRIS integration in question here (Freshteam API). Businesses generally need to integrate with multiple HRIS APIs, meeting the demands of their end customers. Here, a unified HRIS API like Knit can enable businesses to easily integrate with multiple HRIS applications with a single connector. By incorporating an additional layer of abstraction, a unified API allows businesses to ship and scale integrations faster and in an efficient manner. Book a discovery call today to learn how developers can integrate with Freshteam API and other HRIS applications within hours and not weeks. 

API Directory
Apr 9, 2024

A Guide to Integrating with Zenefits APIs


Zenefits API Directory

TriNet Zenefits is a leading provider of full service HR solutions. It enables small and medium sized companies to administer and manage benefits, HR offerings, including time tracking, onboarding, employee engagement, employee record keeping; payroll; performance and well-being. As a highly sought after HRIS platform, companies have been increasingly integrating with TriNet Zenefits to facilitate seamless exchange of HRIS data, captured by Zenefits, with their own apps to drive diverse use cases. 

Zenefits API Authentication, Filtering, Rate Limits

Owing to the sensitive nature of information held by the HRIS application, including personal identifiable information (PII), Zenefits API ensures that all data scopes are accessed at a granular level. The Zenefits API uses OAuth2 to authenticate and authorize access to information stored in the application. OAuth2 authorizes third party applications to request private details from Zenefits accounts, without passwords. It is limited only to admins and developers receive unique Client ID and Client Secret to access data with integration. 

Zenefits API pagination helps developers define the records needed per page. The developers can use the limit parameter to specify the number of records in a response. The maximum limit can be 100, however, in case the limit is not defined, the default limit is 20. In case the total number of records do not fit into a single page, the next_url field will have a link to the next page with the remaining records. In case the next_url field displays null, then no records exist for subsequent pages. Developers can also use the starting_after or ending_before query parameter to specify pagination based on object ids. The ending_before query parameter is useful for backwards pagination. 

Zenefits API Objects, Data Models & Endpoints

It is extremely important for developers to understand the objects, data models and endpoints when it comes to integrating with Zenefits API. While the overall scope might be large, here are a few which can be considered as a starting point for Zenefits API integration. 

  • Applications: Used to return information about the application


  • Companies: Used to get information about the company


Fields include: ‘legal_name', 'ein','departments', 'locations'

  • People: Used to return information about a company’s employees


GET{:id} (For information about a single employee)

GET (For information for all employees across the company)

Fields include: 'work_email', 'date_of_birth', 'manager', 'department', 'location', 'work_phone', 'status', 'subordinates', 'banks','company', 'employments', 'department', 'location', 'manager', 'banks'

  • Employments: Used to return information about an employee’s employment history


GET{:employment_id} (For information on a specific employment

GET (For information on all employments across all people)

Fields include: 'termination_type', 'employment_type', 'comp_type', 'annual_salary', 'pay_rate', 'working_hours_per_week','person'

  • Employee Bank Accounts: Used to return information about employee’s bank account


GET{:bank_id} (For information for a specific bank)

GET (For information for all banks across all people)

  • Departments: Used to return the list of a company’s department


GET{:department_id} (For information regarding a single department:

GET (For information relating to all departments across all companies)

  • Locations: Used to return the list of a company’s location


GET{:location_id} (For information relating to a single location)

GET (For information relating to all locations across all companies)

  • Vacation Requests: Used to return information about employees' PTO vacation requests


GET{:id} (For information relating to a single vacation request)

GET{:vacation_type_id}/vacation_requests/ (For all vacation requests for a single vacation type)

Fields include: 

  • status: Requested, approved, denied, cancelled, deleted
  • vacation_type: Vacation Type for this request, e.g. Jury Duty, Work From Home, Doctor's Appointment
  • start_date: Start date of vacation request (inclusive)
  • end_date: End date of vacation request (inclusive) 
  • creator i.e. Person who filed this vacation request
  • person i.e. Person who this vacation request applies to (often the same as creator)
  • created_date: Date this vacation request was created
  • hours: Number of hours requested, generally calculated at 8 hours a day for multi-day requests and specified manually for single day requests
  • approved_date: Date this request was moved from requested status, either to approved or denied.
  • reason: Note from the person requesting this vacation
  • deny_reason: Note from the approver for why this vacation request was denied. (Only applies if status is denied)

  • Vacation Types: Used to return information about a company's PTO vacation types


GET{:id} (For information relating to a single vacation type)

Fields include:

  • status: Active, deleted
  • vacation_types
  • name: Name of the type
  • company: Company for this vacation type
  • vacation_requests: Vacation Requests for this type
  • counts_as: What account this type counts towards (vacation, sick, personal)

  • Time Durations: Used to return information about a person's T&A hours


GET{:id} (For information relating to a single time duration object)

Fields include: 

  • person: Person that this time duration is logged for people
  • activity: Activity type (work, meal_break)
  • state: Effective, overridden, deleted, correction
  • valid_status: valid, exceeds, overlapping same day, overlapping previous day, overlapping next day, missing clock out, missing clock in
  • hours: Number of hours logged
  • start: When this time duration started
  • end: When this time duration ended
  • is_overnight: Whether this time duration has been marked as part of an overnight shift
  • is_approved: When this time duration was approved. 
  • approver: Person who approved this time duration

Zenefits API Use Cases

  • Automate onboarding, saving 100s of hours as information gets auto synced to Benefits and Payroll
  • Simplify employee management with organizational charts, company directories allowing employees to update their own records
  • Improve HR processes and decision making with business intelligence reports and insights on turnover, workforce diversity, with understanding of how to pay new hires
  • Simplify the process of providing great benefits to employees, from comprehensive healthcare plans to extra perks like commuter benefits
  • Facilitate time and attendance management with employee scheduling tools, with time off and clocked-in hours automatically syncing Payroll

Zenefits API FAQs

Here is a list of FAQs about TriNet Zenefits API which can help commence and accelerate your integration:

  • What is the software stack of Zenefits? Answer
  • How to address the CORS issue in Angular 8 without changing the backend in Zenefits API? Answer 
  • How to handle New Company Installations in TriNet Zenefits API? Answer
  • How to handle New People's Subscriptions in TriNet Zenefits API? Answer
  • What does Webhooks shared secret vs OAuth client secret mean? Answer
  • How to read and write custom data with Zenefits API? Answer
  • How to issue Access Tokens for Zenefits API authentication and authorization? Answer
  • Where can I find a guidebook for Zenefits integration? Answer
  • Does Zenefits have a public API? Answer
  • What is Zenefits’ App Acceptance Criteria for API integration? Answer
  • Where is the developer portal for Zenefits API? Answer

Common Integrations with Zenefits API 

Several businesses are increasingly building integrations with Zenefits API to power operations for the end customers, facilitated by seamless data exchange, including:

  • Payroll providers to get access to employee information, employment records and agreement terms, compensation details and other relevant information like leaves, time off, etc. 
  • Candidate recruitment companies to push data about selected candidates and relevant information for smooth onboarding
  • Employee engagement companies to fetch employee data, including demographic information, personal and professional details, attendance, etc. 
  • Early wage access providers to get access to employee information, payroll details and even write back data regarding early payments/ deductions for accurate payroll processing

How to integrate with Zenefits API 

To get started with the Zenefit API integration journey, a developer account needs to be created. To create the same, developers can reach out to Zenefits team by dropping an email on this email address. Reaching out on this email ID will take the developers to the next step to get access to a sandboxed Zenefits test company and credentials to start using the API. Once the Zenefits developer account is active, developers can leverage this getting started guide for a detailed overview on REST API, Modules, Webhooks, Authentication and much more.  It is important to read through and understand the App Acceptance Criteria well. The same can be accessed here. At the same time, knowledge of the Zenefits Developer Policy is critical to understand the technical, brand and general requirements and restrictions. 

Get started with Zenefits API 

Integrating with Zenefits API is beneficial for businesses looking to seamlessly exchange data with this leading HRIS provider with bi-directional sync. However, building a custom 1:1 integration can be a complex, time and resource intensive process. The above mentioned steps, restrictions and requirements can all choke up developer bandwidth. Invariably, SaaS businesses today are moving away from building integrations to partnering with unified APIs like Knit. A unified API, in this case for HRIS integrations, enables companies to integrate once and seamlessly connect with multiple HRIS applications, including Zenefits API, without any additional requirements. With a unified HRIS API, maintenance and management of integration with Zenefits and other applications also becomes quite easy. Book a discovery call today to learn how a unified API can help you ship and scale integrations fast. 

Start building with Knit, today

Talk to our sales team for a free tour of Knit!

Book Demo!