​

Syncs in Kombo

We’re mirroring the data in the source systems into a database at regular intervals (or when you manually trigger a sync). When you call our API, we will simply read from our database, resulting in endpoints that always respond reliably and quickly. Through our syncing approach, we can also provide webhooks for systems that don’t provide webhooks themselves.

​

Sync Scheduling

Kombo uses a frequency-based scheduling system that automatically determines when syncs should run for each integration.

​

How Scheduling Works

The scheduling system works by tracking the last sync time and adding the configured frequency to determine when the next sync is due. For example, if a full sync completed at 2:00 PM and has a 10-hour frequency, the next sync will be due at 12:00 AM (midnight).

​

Sync Frequencies

Different sync types have different default frequencies:

• Full syncs: Every 10 hours for integrations that support delta syncs, every 3 hours for integrations that don’t support delta syncs
• Delta syncs: Every 3 hours

The exact frequency can be customized on higher plans. When you manually trigger a sync, it moves the schedule forward: Example: If automatic full syncs are scheduled every 10 hours:

• Last sync: 10:00 AM → Next due: 8:00 PM
• Manual sync at 2:00 PM → Next due: 12:00 AM (midnight) (not 8:00 PM)

​

Real-time data updates

In addition to full and delta syncs, we are also able to receive webhooks from selected tools to keep our data in sync more efficiently. Read more about it here.

​

How Syncs Write Data to the Database

Understanding how Kombo syncs write data to the database is crucial for understanding data availability and timing behavior.

​

Non-Atomic Data Streaming

Syncs are not atomic operations. Instead of waiting to commit all data at the end of a sync, Kombo streams data directly into the database as it’s processed during the sync. This means:

• Data becomes available immediately: Updated records appear in API responses as soon as they’re processed, even while the sync is still running
• Partial sync results: If you query the API with updated_after during an ongoing sync, you’ll receive records that have already been processed
• No “commit phase”: There’s no single point where all sync data becomes available at once

​

Change Tracking with changed_at

Each record in Kombo’s database has a changed_at timestamp that tracks when the record was last modified. This field is automatically updated by database triggers when any tracked field changes:

• Immediate updates: changed_at is set as soon as a record is upserted during sync
• API filtering: The updated_after parameter in API requests filters based on this changed_at timestamp
• Real-time availability: Records with updated changed_at timestamps become immediately visible in API responses that use updated_after filtering

​

Sync Lifecycle and Database Operations

During a sync, Kombo performs these database operations:

1. Upsert operations: Each record is upserted (created or updated) immediately when processed. If there were changes, the changed_at timestamp is updated.
2. Deletion tracking: For full syncs, records not seen during the sync are marked with remote_deleted_at after the sync completes successfully.
3. Reference validation: Ensures data integrity by validating relationships between records.

​

Implications for API Consumers

• Progressive data updates: You can start receiving updated data before the sync completes
• Timestamp-based filtering works reliably: Using updated_after will correctly capture changes made during ongoing syncs
• No need to wait: There’s no need to wait for sync completion to access newly updated data
• Consistent behavior: This works the same way for all sync types (full, delta, and default syncs)