What is Knit?

Knit is an event-driven integration platform that helps your dev teams in building customer-facing integrations with minimal effort. Knit does this by offering an embeddable white-labelled UI component that can be embedded in your front-end code. This component allows your end users to securely authorize integrations. Once connected, your product can read and write data through Knit's unified APIs and keep that data up to date through Syncs and real-time events/webhooks.

Knit also follows a no-raw-data-storage architecture, so you can power integrations without storing your users’ raw third-party data in Knit’s database.

One common data model for each category helps your developers expedite integration releases. Further, our white-labelled UI component can be customized to match your app's design palette.

Ready to get started? See How to Setup Knit.

How Knit works

At a high level, this is how Knit fits into your product:

Connect an app
Embed Knit's auth component so your users can authorize integrations without leaving your product.
Establish the connection
Knit validates credentials and creates the connected account.
Read data
Use Syncs to receive ongoing updates over webhooks, or use Knit's GET APIs to fetch data on demand.
Write data
Use Knit's write APIs to create or update records in the connected app.
Scale across apps
Because Knit uses unified data models, your code does not need to change significantly as you add more integrations in the same category.

Core concepts

Knit has a few core building blocks that are useful to understand early.

Auth component

The auth component is how your users connect third-party apps to your product.

You can embed it directly inside your product so users can complete the authorization flow without being redirected to an external admin workflow. Knit handles credential validation and connection setup behind the scenes.

Read next:

Setup Knit UI Component

Unified APIs

Knit's unified APIs let your product read and write data across many integrations using a normalized data model.

This means your application can work with common objects like employees, candidates, jobs, deals, contacts, or journal entries through a more consistent interface, instead of integrating with every provider's API separately.

Use unified APIs when:

You want to fetch data on demand
Your backend needs deterministic read or write access
You want to build once across multiple integrations in the same category

Syncs

Syncs help you keep data updated over time.

Instead of building your own polling infrastructure, you can configure Knit to monitor connected integrations and send change events to your webhook endpoint. Depending on the source system, Knit may use native webhooks where available or poll for changes and deliver them as events.

Use Syncs when:

you want ongoing updates from connected integrations
You want change events delivered to your webhook
You do not want to build polling, delta detection, and event delivery yourself

Read next:

Syncs

Native Webhooks or Real-time events

Some source systems support native real-time webhook subscriptions. Knit supports these where available.

Real-time events can reduce latency, but they are best thought of as complementary to Syncs rather than a replacement for them. In many systems, native webhook payloads are incomplete or inconsistent, so Syncs remain useful as a fallback and consistency layer.

Read next:

Real Time Events Overview

Reading data with Knit

There are two common ways to read data through Knit.

1. On-demand fetch

Use Knit's GET APIs when you need data immediately.

This is useful for:

loading data for a user action
fetching fresh records for a page or workflow
reading data occasionally without maintaining an ongoing sync

2. Ongoing updates

Use Syncs when you want Knit to keep watching for changes and notify your system over webhooks.

This is useful for:

new records
record updates
deleted or inactive records
downstream workflows that depend on fresh third-party data

How Syncs work

Syncs are Knit's preferred way to keep data flowing from connected source systems into your product over time.

When a Sync is active, Knit monitors the configured data models and sends events to your registered webhook endpoint whenever relevant changes are detected.

Broadly, you can expect events such as:

record.new
record.changed
record.deleted
sync lifecycle events such as sync.events.processed and sync.events.allConsumed

Your application should be able to receive and process these events on the registered webhook.

Read next:

Push over pull

Don't call us, we will make sure your data is delivered to you.

With event-driven architectures on the rise, the push model is often easier to work with and scale than a pull model.

In a pull model, your servers continuously call source systems such as HRIS or payroll platforms to fetch data. To do this reliably, you need to build and maintain polling infrastructure. That may be manageable for a small number of jobs, but it becomes much harder as the number of integrations and sync jobs grows. If there is no new data to report, those API calls still consume time and compute.

In a push model, you register a webhook endpoint and receive events when relevant data changes. You do not need to manage polling infrastructure yourself, and you avoid unnecessary calls when there is nothing new to process.

👍
At Knit, Syncs deliver data to your system through webhooks.

Once a Sync has been set up, it will continue running until you pause it.

The first sync that happens after an app is integrated is called an Initial Sync. After that, Knit performs Delta Syncs at the configured frequency to detect changes and deliver relevant events to your webhook.

For more details on event types and webhook behavior, see:

Writing data with Knit

Knit supports two-way integration workflows.

In addition to reading data from source systems, your product can also push data back using Knit's write APIs. Because these APIs use Knit's unified data models, you do not need to build separate write flows for every provider in the same category.

Examples:

Integration Management

Knit also helps with the operational side of integrations.

When a user attempts to connect an app, Knit validates the connection and surfaces relevant status through the auth flow. If there are common setup issues, users can see descriptive error messages and suggested resolution steps directly in the UI component.

Integration error reported on UI Component

Knit also gives your team visibility into sync activity. Through the Knit app, you can review sync runs, see what data was synced, when a sync ran, and whether any issues occurred.

Security and data handling

Knit is built with a no-raw-data-storage architecture.

A few important principles:

Knit's write APIs are pass-through in nature.
Knit does not store your users' raw integration data in its database.
Syncs detect changes and normalize data for delivery without persisting raw customer records.
Data is encrypted at rest (AES-256) and in transit (TLS 1.2).
Knit is built with enterprise security requirements in mind, including SOC 2, GDPR, ISO 27001, and HIPAA-readiness.

👍
Knit lets you power integrations without storing your users' raw third-party data in your integration layer.

Latency

Once an app has been integrated and a sync has been set up, you can expect data on the registered webhook in a matter of seconds. Typically, a sync will get over in minutes. But this is all subject to API rate limits and timeouts.

The best way to track the completion of a sync run is either receipt of sync.events.allConsumed event or matching the number of events actually received by your webhook and comparing it with the count of emitted events in sync.events.allEmitted event payload.

Supported integrations

Knit supports integrations across multiple categories, including HRIS, ATS, CRM, Accounting, Ticketing, Meetings, and more.

See the full list here: All supported apps

Ready to try Knit now? Sign up and check out Knit's API Reference