The following are the fundamental ideas behind how Knit handles data, covering sync behavior, data flow, and how everything stays up to date.

Push vs Pull

In simple terms, Push vs Pull defines how data is transferred, whether you fetch it yourself (pull) or the system sends it to you automatically (push).

Don’t call us - we’ll deliver your data to you.

Let’s take a closer look at what both models mean and how Knit’s approach to the push model helps you build faster, smarter integrations.

What is a Pull Model?

To understand why Knit takes a different approach to data delivery, it’s helpful to look at how the traditional pull model works. In a pull-based setup, your backend system takes on the responsibility of checking in with the data provider, such as an HR, CRM, or payroll platform, again and again to ask, “Do you have any new data?” This repetitive process is known as polling, and it continues whether or not there’s anything new to retrieve, as illustrated below:

This approach not only increases unnecessary traffic between systems but also leads to wasted resources, especially when you’re running hundreds or even thousands of polling jobs, and most of them return empty responses. The result is inefficient use of computing power and delayed responsiveness, all while still missing out on real-time updates. This makes the pull model less scalable and less suited for fast, modern integrations where timely data delivery is critical.

What is a Push Model?

Unlike the pull model, instead of your systems repeatedly asking, “Is there any new data?”, imagine a setup where data comes to you only when there’s something new to share. That’s the essence of the push model, and it’s exactly how Knit works behind the scenes.

How it Works

Once you tell Knit where to send updates by registering a webhook (just a simple URL), Knit starts listening for any changes from your connected tools. There are two ways we keep your data up to date:

✅ Scheduled Syncs (Virtual Webhooks): For systems that don’t support webhooks natively, Knit polls the source system at regular intervals, which can be customized to run as frequently as every 5 minutes. Whenever changes are detected, Knit sends these updates to your webhook, giving you near real-time updates even if the system doesn’t support webhooks out of the box.

✅ Native Webhooks Support: For systems like HubSpot or Lever, which can send webhooks when data changes, Knit listens for those native webhooks directly. When we receive them, we instantly relay the updates to your app, so you always get real-time data.

This flexible approach ensures you get timely, reliable updates, whether your connected system supports webhooks or not. No more redundant polling, wasted resources, or missed changes — Knit handles everything behind the scenes, including retries and delivery confirmations, so you can focus on building great features.

The data flow looks like this, as illustrated below:

The Power of the Push Model

Knit is built on a proactive communication model, rather than waiting for you to ask, it delivers updates the moment something changes. Once you specify where to send this data by registering a webhook, Knit takes over.

It continuously watches your connected systems for any relevant changes, detected either via polling or native webhooks (where supported by the connected system). As soon as new data becomes available, Knit immediately pushes it to your destination, ensuring your systems stay current without delay or extra effort. There's no waiting, no repeated checking, just real-time updates delivered with precision.

This method reduces system strain, avoids unnecessary processing, and guarantees you always have the latest information at your fingertips automatically.

Why it’s better:

✅ No polling. No, asking again and again. ✅ You get data only when it matters. ✅ Knit handles all the heavy lifting, retries, failures, and delivery tracking.

How Knit Makes Push Reliable

Knit goes beyond just sending updates - it makes sure your data syncs stay reliable and smooth, even when there are issues. Here’s how:

✅ Retries When Things Go Wrong: If your system is down or temporarily unavailable, Knit doesn’t give up. It keeps trying to send your updates automatically for up to 4 days. This way, you don’t miss important data just because of a momentary glitch.

✅ Idempotency to Avoid Duplicate Data: Every event that Knit sends comes with a unique eventId. This helps your system recognize if it’s already seen an update, so you can skip duplicates and keep your data clean and accurate.

✅ Confirmation When Syncs Finish: After sending all updates in a sync cycle, Knit sends a special confirmation event called sync.events.allConsumed. This lets your system know that every update has been delivered successfully, so you don’t need to guess if something was missed.

✅ **Reliable Polling When Webhooks Aren’t Available: **Sometimes, the apps you connect don’t support webhooks, so we can’t get notified automatically when data changes. In these cases, Knit uses polling - we check those apps regularly for changes. But polling can be tricky because it’s easy to go over rate limits or lose connection. Knit takes care of this by:

Smart Rate Limit Management: We make sure our polling stays within the allowed limits of each connected app. That means we don’t overload their servers or get blocked, and your syncs keep working smoothly.

Automatic Token Refreshing: Most systems require tokens for secure access, which can expire over time. Knit refreshes these tokens automatically in the background so that your connection stays active. You don’t have to manually reauthorize or worry about interruptions.

Note: These built-in features ensure you get every update reliably, whether Knit is pushing data or polling for it, all without you needing to build any of this yourself.

Why Knit Chooses Push

Knit chooses the push model because it offers a smarter, more efficient way to handle data syncing, especially for modern systems that rely on real-time, event-based interactions. Instead of constantly checking for updates, Knit is designed to react the moment something changes. That’s why all data syncs in Knit are powered through webhooks. This approach ensures that your systems stay updated exactly when needed, without wasting resources or relying on constant checks.

At Knit, we’ve built our entire sync infrastructure around this model because it’s faster, more reliable, and simply makes more sense for today’s integration needs.

ℹ️

At Knit, we love the push model. All data syncs at Knit happen through webhooks.

How Data Arrives (Push Webhooks)

1. Register a webhook URL in your system; this is where Knit sends updates.

2. Knit watches connected apps (like HR or CRM) and detect changes.

   When something changes, Knit sends a POST to your webhook with the event data (e.g., record.new).

3. Your server processes the data and replies 200 OK.

4. If something goes wrong, Knit automatically retries for up to 4 days and signals when all events are emitted & consumed.

To better understand this flow, let’s walk through the Knit Data Sync process step by step.

Knit Data Sync

At Knit, syncs are the go-to method for reading data from other systems. Once you set up a sync, we continuously push data directly to your endpoint, no polling required.

To get started,

• You simply tell Knit what kind of data you want.
• Select a data category, such as Employees, Contacts, or Invoices.
• Choose the specific models you want to retrieve within that category, such as employee compensation details, contact information, or invoice amounts.
• Provide the webhook URL where Knit should send the data updates.
• Once setup is complete, Knit begins polling the source system in the background.
• For the first sync, Knit sends all the source data to your webhook. This is what we call an initial sync.
• Thereafter, whenever a new record is created or existing data changes, Knit automatically sends the updated information to your webhook. This is what we call delta syncs.
• You don’t need to do anything else; Knit keeps your data up to date automatically.

1. Syncs Start Automatically or Manually

When you connect an app like HubSpot or BambooHR, you now have a choice: you can let Knit start syncing automatically right away, or you can choose to manually start the sync when you’re ready. This gives you more control over when your data begins to flow.

If you prefer manual control, Knit provides an API to start syncs programmatically whenever you want.

Note: To see how to manually start a sync whenever you need, check out the Start a Sync API guide.

Either way, once syncing begins, Knit will keep your data up to date in the background until you pause or stop it through the dashboard or API.

2. Two Types of Syncs

To keep your data both accurate and efficient, Knit uses two different sync strategies depending on the stage of the connection.

The Initial Sync kicks in when an app is first connected, fetching all existing records to establish a complete baseline. After that, the Delta Sync takes over, capturing only the new or changed data going forward. This ensures you get updates without redundancy, reducing load while keeping everything in sync automatically.

You’ll receive updates in real time, right when Knit detects something worth sending.

3. Event Types You'll Receive

Knit categorizes data updates using five main event types, sent to your webhook:

✅ Make sure your code can handle all five event types on your registered webhook.

ℹ️

Need help getting started?

Check out the guides on Registering your Webhook URL and Starting a Sync to set up your integration the right way.

3. Event Delivery Guarantees

i. Knit will attempt to deliver the event to the webhook you registered during the sync setup process.

ii. Your server is expected to respond with an HTTP status code 200 OK to confirm that the message was received and processed successfully.

iii. If message delivery fails, Knit will automatically retry sending the event for up to 4 days. After that period, retries will stop. If needed, you can manually trigger a complete sync for the integration using Knit’s web app or API.

Note: Triggering a sync will resend all records expected in that sync run; you can’t trigger a single record on its own.

To see how to manually start a sync whenever you need, check out the Start a Sync API guide.

iv. Knit sends an additional event of type sync.events.allEmitted once all events in the current sync run have been emitted. This event includes the total count of events sent. It’s useful for tracking what Knit delivered, but keep in mind, the order of events is not guaranteed, so don’t rely on it for processing logic.

v. After all events have been successfully received and acknowledged by your server, Knit will send another event of type sync.events.allConsumed. This marks the completion of that sync run and can be used as a reliable trigger for starting any downstream workflows on your end.

Note: Make sure your webhook handler correctly acknowledges each event (200 OK) and gracefully handles retries or duplicates.

Unified Data Models

Knit transforms data from all kinds of apps into consistent, easy-to-use objects. Whether you're working with HR, CRM, accounting, or ticketing tools, you always get familiar entities like **Employee, Contact, Invoice, Expense, **and more.

This means instead of handling 10 different HR tools with 10 unique schemas, you work with one unified model like "Employee" having the same fields, same format, every time.

Instead of dealing with different field names and formats across each app, Knit standardizes everything into a single, shared structure:

• Same field names (e.g., id, email, name, status)
• Same data types (text, date, number)
• Same structure, no matter the source

This means each time you pull data, you're working with a predictable model - no surprises or extra mapping needed.

Limitations (Coverage Matrix)

Not all SaaS apps support every data model or filter capability. This is where Knit’s Support Matrix becomes essential. The matrix outlines which entities, such as Invoices, Contacts, or Employees, are available for each app.

It also details the applicable filters you can use per entity, like status, date, or tags. Knit does not set these limitations but depends on the capabilities of the underlying third-party platforms.

Tip: Before building any sync, it's highly recommended to consult the support matrix. It helps you understand what data can be retrieved and how it can be filtered. For instance, while one app might support filtering invoices by date, another may not offer that option at all. The matrix gives you this clarity up front, so you can plan your syncs effectively and avoid surprises down the road.