Syncs

Use Syncs to receive change events from third-party systems without building your own polling infrastructure.

Knit offers Unified APIs, LLM tools, and MCP servers as an integration platform. Across all of these, a common need is not just to read data once, but to know when it changes.

Examples:

• A new employee is created in an HRIS
• A candidate is updated in an ATS
• A deal changes stage in a CRM
• A new ticket is created in a support platform

Some third-party platforms offer native webhooks for these events. Many do not. And even when native webhooks exist, they are often incomplete, inconsistent, or only act as a signal that your system should fetch the latest data again.

Without Knit, teams usually end up building cron jobs to poll APIs, compare results with previous runs, detect changes, and trigger downstream workflows.

Syncs handles that for you.

What Syncs do

A Sync is Knit’s managed polling, delta-detection, and webhook delivery layer.

When you create a Sync, Knit:

1. polls the configured object(Employees, Applications, Deals, Invoices etc) at the configured frequency
2. compares the latest result with prior fingerprints of the data
3. detects changes such as new or updated records
4. sends those changes to your webhook endpoint as events

This lets you treat polling-based integrations like event-driven integrations.

Why use Syncs

Without Syncs, teams typically need to:

• Run scheduled jobs
• handle retries and failures
• fetch records repeatedly from source systems
• Compare current data with prior runs
• identify meaningful deltas
• emit internal events for downstream workflows

With Syncs, you only need to:

• Define the object sink you want to monitor
• Choose a polling frequency
• register a webhook endpoint
• Listen for Knit events

How Syncs work

1. Configure a Sync

Syncs are configured at the object level.

When setting up a Sync, you define:

• The sync for the object you want to monitor
• The sync(polling) frequency
• The webhook endpoint that should receive events

To start a sync, use the Start a Sync API.

2. Knit polls on a schedule

At the configured interval, Knit fetches data for that object from the third-party system.

The default polling frequency is 24 hours.

Polling frequency can also be adjusted based on your use case. Depending on how you model your setup, you may choose to configure it:

• per integration instance
• at the category level
• According to the operational importance of the data

For example:

• CRM data may be polled every 15 minutes because it is operationally time-sensitive
• Employee data may be polled once or twice a day because it changes less frequently

To change the frequency of an existing sync, use the Update Sync Frequency API.

If you want the sync to run at a specific time, such as 00:00 daily, use the Sync Start Time API.

3. Knit detects deltas without storing raw customer data

Knit compares current results with prior fingerprints of the data to identify changes.

Knit does not need to persist raw customer data in order to detect changes. Instead, it compares hashes of previously seen data, allowing Knit to determine whether something changed without storing the underlying customer records.

Depending on the integration and object, detected changes may include:

• new records
• updates to existing records
• other meaningful state changes supported by the integration(deletion/termination)

For the list of event types emitted by Knit, see the Event Glossary.

4. Field-level change detection

By default, Syncs tracks changes across all fields included in the synced object.

For example, if you are syncing an employee profile, Knit emits a record.modifiedevent when any of the selected profile fields change.

This default behavior works well for most use cases. However, in some cases or categories, such as CRM or accounting, you may only want to detect changes for specific fields that matter to your workflow.

For those cases, Knit supports watch fields.

Watch fields let you define the specific fields that should be monitored for change detection. Instead of triggering modification events for any field update, Knit only emits change events when one of the configured watch fields changes.

This is useful when:

• Only a subset of fields is operationally important
• You want to reduce unnecessary downstream events
• You need more precise control over delta detection for high-change objects

To configure this behavior, see Sync Watch Fields.

5. Knit sends webhook events

Once a change is detected, Knit delivers that event to the webhook URL you registered.

Your application can then use those events to:

• trigger business workflows
• update internal records
• send alerts or notifications
• kick off downstream automation
• notify AI agents or other systems that fresh data is available

To receive these events, first register your webhook URL.

Native webhooks and Syncs

Some platforms support native webhooks, and Knit supports subscribing to them wherever available.

However, native webhooks often vary across systems:

• Some send only partial data
• Some act only as notifications that require a follow-up fetch
• Some are inconsistent across objects or integrations
• Some can miss events or behave differently under load

Because of this, the general recommendation is:

Use native webhooks where available, and use Syncs as a backup layer.

This gives you a more reliable setup while still allowing you to receive all events through the same webhook URL you registered with Knit.

In practice, with native webhooks / realtime events - Syncs acts as a safety net that helps ensure no data is lost, regardless of how different third-party systems implement native webhook support.

To learn more about Knit’s native webhook support, see Native Webhooks / Realtime Events.

Common use cases

Detect new records

Examples:

• new employee in BambooHR
• new deal in Salesforce or HubSpot
• new candidate in Greenhouse

Detect updates to existing records

Examples:

• employee status changed
• ticket priority updated
• opportunity stage changed
• account ownership changed

Trigger downstream workflows

Examples:

• create internal alerts
• sync data into your product database
• launch workflows in your app or automation tool
• notify an AI agent that fresh data is available

Developer experience

The integration pattern is simple:

1. register a webhook endpoint
2. create a Sync
3. Choose a polling frequency(optional)
4. Authenticate and receive events from Knit

You do not need to:

• build cron jobs
• manage polling infrastructure
• persist snapshots of raw customer data
• Implement delta detection for each connector,
• normalize different webhook behaviors across systems

If you need to stop processing temporarily, use the Pause a Sync API.

Example

A product wants to notify onboarding teams whenever a new employee is created in a connected HRIS.

Without Syncs:

• The product runs a scheduled job every few hours
• fetches employee records from the HRIS
• stores prior state or snapshots
• compares the latest results with earlier results
• identifies new employees
• creates internal events
• triggers notifications

With Syncs:

• The product creates a Sync for the employee object
• sets the frequency to once or twice a day
• registers a webhook endpoint
• Knit detects changes using prior data fingerprints
• Knit sends webhook events whenever new employees are detected

Another example:

A RevOps workflow needs to know whenever a CRM deal changes.

With Syncs:

• the product creates a Sync for the deal object
• sets the frequency to every 15 minutes
• receives change events on its Knit webhook endpoint
• uses those events to trigger downstream workflows

Best practices

• Use shorter polling windows for time-sensitive systems like CRMs
• Use longer polling windows for lower-change systems like HRIS employee data
• Subscribe to native webhooks when available
• Also enable Syncs as a backup to improve reliability and consistency
• Use one webhook endpoint to process both webhook-driven and sync-detected events from Knit
• Review the Event Glossary so your application handles event types correctly
• Use watch fields when only specific fields should trigger modification events

Managing Syncs

You can manage the lifecycle of a sync using the following APIs:

• Start a Sync
• Pause a Sync
• Update Sync Frequency
• Set Sync Start Time
• Filtering Data in Syncs

Summary

Syncs are Knit’s managed polling and delta-detection layer.

It turns systems without reliable native webhooks into event sources by:

• polling on a schedule
• detecting changes using prior data fingerprints
• preserving Knit’s no-storage promise
• delivering changes over webhooks

It also complements native webhooks by acting as a backup layer when those webhooks are incomplete, inconsistent, or lossy.

If your application needs to know when third-party data changes, but you do not want to build and maintain polling infrastructure yourself, use Syncs.

---