Kombo vs. Unified.to: Sync-and-Store vs. Live Source Reads (2026)

June 4, 2025

Updated September 2026

Kombo and Unified.to are both unified APIs, and the surface-level pitch looks similar: connect once, reach many systems behind one common data model. Look at how each one moves data, though, and they're built on opposite foundations.

Kombo syncs a copy of your customers' HR and recruiting data into its own database and serves your API calls from that store. Unified.to runs every API call against the source system at request time and stores no business data at rest. That one decision, store a copy or read the source live, drives the differences that matter: how current the data is, what compliance footprint you inherit, whether the data behind an escape hatch is live or synced, and how each behaves under an AI agent.

This is the comparison that counts, and it isn't breadth versus depth. Both model HR systems in field-level detail, and both publish that coverage per integration. The question is architecture.

For other single-vertical comparisons in this cluster, see Finch vs. Unified.to (the HRIS-focused unified API comparison) and Nylas vs. Unified.to (the communications-focused unified API comparison). For a broader survey, see Top Merge.dev Alternatives in 2026.

What's the architectural difference between Kombo and Unified.to?

Kombo is sync-and-store. When a customer connects an HRIS, payroll, ATS, assessment or learning system, Kombo syncs their records into its own database and keeps them updated. In Kombo's own words, it is "mirroring the data in the source systems into a database" at regular intervals, and your API calls read from that copy. Kombo's docs then recommend upserting what it returns into your own database. A Passthrough API calls the source system's own API directly for cases the common model doesn't cover.

Unified.to reads the source live. Each API call routes to the source system at request time and returns the result without caching the payload. There's no mirrored database of candidate, employee or payroll records. Only tokens and operational metadata are persisted, encrypted with AES-256, and from the Pro tier up those credentials can live in your own AWS, Azure, Google Cloud or HashiCorp secrets manager instead of Unified.to's database.

These are two generations of the same idea. The first generation of unified APIs solved the integration problem by mirroring data into a store and serving it from there: batch sync, a common data model on top, and the storage and staleness that come with it. It's the pattern Kombo, Merge and Finch are all built on. The next generation keeps the unified schema but drops the store: requests reach the source live, no customer business data rests in vendor infrastructure, and how current the data is isn't a sync setting. These aren't better and worse versions of one architecture. They're the before and after of a shift in how the problem gets solved.

You can read the difference directly off Kombo's own data model. Records in Kombo's database carry a changed_at timestamp, and entries it can no longer find during a sync are marked with remote_deleted_at, with the fields set to null 14 days later. Those fields exist because the data lives in Kombo's store and has to be reconciled against the source over time. Kombo's documentation notes that delta syncs can't detect deletions, so deletions are found by full syncs, which run less often. Its guidance also tells you to compare nested data to work out what actually changed, and to run a periodic full fetch, ideally weekly, to correct drift including from lost webhooks.

A live-read layer has no stored copy to reconcile. The trade-off runs both ways: Kombo gives you an explicit remote_deleted_at flag once a completed full sync no longer finds a record, and deleted records can be retrieved with include_deleted, while a live read shows only that the record is no longer returned, unless the source system sends a delete event.

Neither approach is wrong. They optimize for different things, and the rest of this comparison is downstream of this one choice.

What do live source reads buy you?

Three things follow from reaching the source live instead of a stored copy.

The data is current, not as-of-last-sync. When Kombo serves a read, you get the state of the data as of its last sync or processed source webhook. On integrations where Kombo subscribes to source webhooks, changes typically arrive within 10 to 20 seconds. Elsewhere, syncs run on a 3-hour default, configurable down to five minutes, with faster intervals on Scale and Enterprise, and a sync can be triggered manually. When Unified.to serves a read, the call reaches the source system and returns what's there now. For an in-product recruiter view or an employee record a user is actively editing, the difference between "now" and "as of the last sync" is the difference between showing correct data and showing stale data. Kombo's own read path is unchanged either way: a source webhook updates Kombo's database, and your call still reads from that copy.

If the vendor is breached, it's your customer's data. Sync-and-store means your customers' people data, which is personal information and often falls in regulated categories, is persisted in the vendor's infrastructure. That makes the vendor a subprocessor, so your customer has to disclose them, list them in their DPA, and carry them through every security review. For enterprise buyers this often decides the evaluation before it starts: a CISO who won't approve a third party holding employee records won't approve the integration that depends on one. Live source reads mean that data never comes to rest outside the source system and your own product. For teams whose answer to a security questionnaire is "no third party stores your people's data," this is architectural, not a policy you have to trust.

There's no sync to wait on or to break. A stored model needs an initial sync before it's usable, a few minutes for most integrations and up to several hours for a large instance by the figures on Kombo's ATS FAQ, and an ongoing reconciliation loop that can lag or drift. Kombo's guidance recommends a periodic full fetch, ideally weekly, to correct drift including from lost webhooks. Live source reads have no warm-up and no drift: the first call works and every call reflects the source.

Does the common model limit which fields you can reach?

The usual objection to a common data model is that it can't cover every field of every system, so you lose access to the long tail. You're not locked into Unified.to's version of the universe, and there are two ways out:

• Raw fields alongside the unified object. Request raw in the fields parameter and the response includes the original source payload next to the unified object, including platform-specific fields that aren't in the common model. Some platforms, HubSpot and Salesforce among them, return custom fields only when you name them, so you add them with a raw. prefix (fields=id,name,raw,raw.leadFunnelStage). Writing platform-specific attributes works the same way in reverse, inside a raw object in the request body, and the source system's own record ID stays available at raw.__id if you need it for a Passthrough call. The common model is the default, not the ceiling.
• The Passthrough API for anything unmodelled. When you need an endpoint or object that isn't in the common model at all, call the Passthrough API with the connection, path, method and body. Unified.to handles authentication and routing and returns the native response, through your existing connection.

Both mechanisms read the source live, so reaching beyond the common model doesn't move you onto a different, staler code path. Kombo offers comparable escape hatches, so this isn't a capability only one vendor has: custom fields and field remapping on reads, remote fields on writes, raw remote_data on records, and a Passthrough API that calls the source system's own API directly. The difference is where the data comes from. On Unified.to, the unified call and the raw call both read the source live. On Kombo, the unified read and the raw remote_data both come from its store, because raw payloads and integration field values are collected during a sync and saved. Its Passthrough API is the live path.

How does authorization work, and whose name do your customers see?

The first problem with data integrations isn't the API. It's getting your customer to authorize access to theirs. Connecting to Workday or BambooHR is the straightforward part. The harder problem is getting someone who doesn't know your product yet, probably isn't technical, and may not fully trust you, to hand over access to their core business data.

One authorization flow covers every integration, whether OAuth2, API keys, tokens or custom auth models, without your customer needing to understand what's happening underneath. On OAuth2 integrations you register your own developer app with each vendor, so the consent screen your customer sees carries your name, logo and privacy policy, and you control which permissions are requested. On integrations that authenticate with an API token, the authorization page shows your workspace name, and you can replace auth.unified.to with your own domain through a CNAME record, with your own favicon. The embedded authorization component ships as React, Vue, Angular and plain JavaScript packages, can be forked and restyled completely, and picks up newly activated integrations without a code change. Kombo's connection flow shows Kombo's branding by default; its own logo and name can be replaced through partner credentials on integrations that support them, and Kombo notes that support varies by tool.

When is Kombo the better choice?

Sync-and-store is a real engineering choice with real advantages, and for some products it's the right one.

• A queryable copy you don't have to host. For workloads that query the same records many times and don't need them current to the second, such as historical reporting, batch analytics and internal dashboards over employee data, serving from a store avoids repeated round-trips to the source. Kombo runs that store for you. Unified.to's answer to the same workload is Database Sync, which streams the records into your own database, so you own the copy but you need a database to sync into and you query it yourself. If you'd rather not run one, Kombo's architecture removes that step.
• HR-category focus. Kombo builds only for HR, payroll, recruiting, assessment and learning systems, documents recruiting-specific features per integration such as candidate source writing and screening-question answers, and offers AI Apply, which turns job posting URLs into an API surface for creating applications.
• ISO 27001 certification. Both hold SOC 2 Type II and comply with HIPAA and GDPR, and both offer regional data residency: Kombo lists US, Canadian and EU data centres, and Unified.to offers US, EU and Australia. Kombo's compliance edge is ISO 27001, which Unified.to does not currently hold. For enterprise procurement that requires ISO 27001 specifically, that's a real differentiator.
• A published uptime SLA. Kombo lists an uptime SLA as a plan feature on Scale and Enterprise, and a support SLA on Enterprise. Unified.to doesn't offer a standard SLA on the API or webhooks, though uptime and error-rate commitments have been written into some custom agreements. If a contractual uptime commitment has to be a line item rather than a negotiation, that's a real difference.
• Per-customer pricing. Kombo charges a platform fee plus a per-customer connection fee rather than per API call, with unlimited calls inside each connection, and its per-customer fee decreases at scale. That decouples cost from call volume, which helps if you have many customers each generating heavy usage. The trade-off is that cost scales with customer count rather than usage.
• Hands-on support. Kombo offers white-glove onboarding calls with your customers on its Enterprise plan, and support is a recurring theme in its G2 reviews.

If your product is HR-tech first and your access pattern is frequent reads over cached records, Kombo's architecture is built for that. The trade-off you're accepting in return is that your customers' people data lives in Kombo's infrastructure, and reads are as current as its last sync or processed source webhook rather than as current as the source.

How does Kombo's coverage compare to Unified.to's?

Integration and category counts move as both catalogues grow. The figures here are current as of September 2026, and Unified.to's live matrix is the canonical source. Unified.to covers the same future-of-work categories Kombo does, HRIS and payroll, ATS, assessment and background check, and LMS, plus identity and directory, and then more than two dozen on top, including CRM, Accounting, Marketing Automation, Messaging, Calendar & Meetings, Ticketing, File Storage, Enrichment, and AI Tooling: 33 categories across 969 integrations in total. Kombo's four unified APIs cover 250+ integrations by its own published figure. Unified.to covers every category Kombo does and more than two dozen others, though each catalogue lists systems the other doesn't, so check both against the specific systems your customers run.

The point isn't a count contest. It's that every category Unified.to covers reads the source the same way, so HR, CRM, accounting and messaging all behave alike: live reads, no stored copy, and raw and Passthrough access to each source. A product that needs HR plus other categories integrates one vendor with one set of architectural guarantees, instead of pairing an HR specialist with separate vendors for everything else, each with its own data-handling posture to evaluate. Kombo makes the same point in its own buyer's guide: companies that need integrations beyond HR, such as accounting and CRM, will need to combine Kombo with other specialized solutions.

Unified.to publishes a per-integration capability matrix: which objects, fields and webhooks are supported for each system, visible before you commit. Kombo documents supported fields and operations publicly too, per integration and per operation, with an interactive coverage grid available to customers in its dashboard.

How do Kombo and Unified.to compare for AI agents?

The architecture difference shows up most sharply under an AI agent. An agent reasoning over a stored copy is reasoning over data that is as current as the vendor's last sync or processed source webhook. An agent over a live-read layer reads the source at the moment it acts, so it reasons on what's true now rather than on what was true yesterday. The stakes differ from analytics: one bad data point among millions is noise in a report, and a wrong decision that costs money in an agent.

Unified MCP has supported the stateless protocol core of the 2026-07-28 MCP revision since the day that revision was finalized. That revision removes the initialize handshake and the protocol-level session: every request carries its own protocol version, client identity and capabilities, and routing information travels in HTTP headers, so a gateway routes an MCP request without reading the JSON-RPC body. In deployment that means round-robin load balancing, no sticky routing and no shared session store, and MCP requests cross corporate gateways and firewalls on the same terms as any other HTTP request. That is the constraint that mattered: a stateful protocol needed special handling everywhere it went, so MCP was frequently unusable from inside a corporate network, and for agents running there reachability was the binding constraint rather than integration coverage. Clients built against earlier revisions keep working. (MCP v2 is here)

Unified MCP has two modes. Point it at a single end-customer connection and it exposes that connection's integration-specific tools. Authenticate with a workspace key alone and it exposes management tools for your own configuration data, which reads no end-customer data at all. Each connection gets its own URL, and that URL can carry a signed token scoped to exactly one connection, so it never exposes your workspace key and is safe to hand to a customer. hide_sensitive strips personal information, including names, emails and telephone numbers, before results reach the model; permissions and tools restrict which tools are exposed at all; and defer_tools defers loading to reduce context use. Transport is Streamable HTTP, with SSE deprecated in the protocol, and a region parameter selects US, EU or AU. 22,566 callable tools span 969 integrations, reading and writing, so agents can query records and trigger actions across HR and every other category, and include_external_tools adds each vendor's raw passthrough endpoints as callable tools on top of the unified ones. A single tools endpoint returns provider-shaped output for OpenAI, Anthropic, Gemini, Cohere, Grok and Groq. Each tool call counts as one API request on your plan.

Kombo publishes no MCP server as of September 2026. Its AI-related products are AI Apply, which turns job posting URLs into an API surface for creating applications, and browser-agent integrations, which read and write structured data in systems that don't provide an API, with ATS as the primary scope.

How do Kombo and Unified.to compare on security and compliance?

How does Kombo's pricing compare to Unified.to's?

Kombo is quote-based across all three tiers, Start, Scale and Enterprise, with no public dollar amounts and a demo request on every tier. Its model is a platform fee plus a per-customer connection fee, with unlimited calls per connection, and its per-customer fee decreases as you scale.

Unified.to publishes entry pricing across four tiers: Grow at $750/month for 750,000 calls; Pro at $1,500/month for 2M calls, adding SAML SSO, customer-managed secret storage and IP restriction; Scale at $3,000+/month for 6M calls, adding HIPAA BAAs, 365-day log retention and a lower overage rate; and Enterprise (custom) with single-tenant, private-cloud and on-prem options. All tiers include unlimited customer connections, integrations, webhooks, Database Sync and custom fields, plus all 33 unified APIs, with API call overages the only additional usage cost.

The models decouple cost from different things, and they pull in opposite directions as you grow. With a per-customer model, your cost rises with every customer you onboard; with a per-connection model, it also rises with every integration each customer connects. Either way, adoption itself raises the bill. With Unified.to's usage-based model, customers and connections are unlimited, cost tracks API activity, including one request per MCP tool call, and unit price drops as volume grows. Adding integrations to existing customers doesn't multiply spend, and customer growth that doesn't drive activity doesn't compound it.

The one place usage-based pricing needs discipline is heavy read volume, meaning high-frequency or analytical workloads that would run up calls. The answer isn't a different pricing model. Database Sync, included on all plans, streams records to your own database, whether Postgres, MySQL, MongoDB, MSSQL, CockroachDB or MariaDB, for analytics and high-volume cached reads, so you can reserve live API calls for the data that has to be current. Those reads happen outside the per-call quota, and the data lives in your infrastructure, not Unified.to's. That's the distinction worth keeping in view: the objection to sync-and-store isn't that a cached copy is never appropriate, it's that a vendor holds your customers' data and your reads default to that copy. So the comparison is this: per-customer pricing is easy to model but taxes growth; usage-based rewards it, provided you use webhooks and Database Sync for the workloads that don't need a live call. Run your own numbers against your projected customer count, integrations per customer and call volume.

Customer spotlight: how Humi shipped 25 HRIS integrations in one month

Humi is a Canadian HR platform serving thousands of businesses across HRIS, payroll and benefits. As their integration catalogue grew, the native-build math stopped working: every new HRIS integration was weeks of engineering, and maintenance compounded.

With Unified.to, Humi shipped 25 HRIS integrations in one month, work Humi's team estimated would have taken more than seven years to build natively, using the HR API plus Passthrough access for vendor-specific edge cases, all behind one API surface. Humi's CEO describes Unified.to as "impressively fast at responding to our integration requests and adding them within days."

Humi is the relevant data point for this comparison because it's an HR-first product that chose a multi-category vendor reading each source live. When integrations span employee data plus the systems around it, CRM for sales handoffs, accounting for payroll exports, calendar for onboarding, one vendor with one architecture beat pairing an HR specialist with separate vendors for everything else.

How do you choose between Kombo and Unified.to?

Kombo fits if you want a queryable copy of people data that the vendor hosts, rather than syncing it into a database you run yourself; ISO 27001 plus in-region data isolation is a procurement requirement; a contractual uptime SLA has to be a plan feature rather than a negotiation; or per-customer pricing that isn't metered on call volume fits your unit economics.

Unified.to fits if you want live access to the source rather than a synced copy; you need no customer business data resting in vendor infrastructure; you need HR plus other categories from one vendor on one architecture; you're building AI agents that must act on current data through a managed MCP layer; or you want customer-managed secrets, an authorization flow that carries your own branding and domain, and self-serve entry pricing.

Frequently asked questions

Is Kombo a unified API?

Yes, for future-of-work systems. Kombo offers four unified APIs, covering HRIS and payroll, ATS, assessment and background check, and LMS, with systems such as Personio, BambooHR, Workday, Greenhouse and Lever behind a common model per category. The difference from horizontal unified APIs is scope: Kombo's covers HR and recruiting; Unified.to's spans 33 categories including those.

Does Unified.to cover the same HR and ATS systems as Kombo?

Largely, yes. Unified.to's HR category covers Workday, BambooHR, Gusto, ADP, HiBob, SAP SuccessFactors, Personio and others; its ATS category covers Greenhouse, Lever, Ashby, Workable, JobAdder, SmartRecruiters and more, all reading the source live. Both catalogues also list systems the other doesn't, including on both sides in Europe, so check both against the specific systems your customers run, including variants and stage labels.

What's the practical difference between sync-and-store and live source reads?

Sync-and-store keeps a copy of your customers' data in the vendor's database and serves reads from it, which is fast for repeated queries but as current as the last sync or processed source webhook, and resident in vendor infrastructure. Reading the source live returns current data with no business data at rest, at the cost of a round-trip per request. Kombo is the former; Unified.to is the latter.

Does the common model limit which fields I can reach?

No. On Unified.to, the raw envelope returns the original source payload alongside the unified object and accepts platform-specific fields on writes, and the Passthrough API reaches unmodelled endpoints live. The common model is the default, not the ceiling.

Whose branding do my customers see when they connect?

On OAuth2 integrations, yours: you register your own developer app with each vendor, so the consent screen carries your name, logo and privacy policy. On integrations that use an API token, the authorization page shows your workspace name, and you can point your own domain at it through a CNAME record and set your own favicon. The embedded component can also be forked and restyled completely. Kombo's connection flow shows Kombo's branding by default, replaceable through partner credentials on integrations that support them, and its docs describe no custom domain.

Does Kombo have an MCP server?

Not as of September 2026: Kombo's docs, changelog and GitHub show no MCP server or announced plan. Its AI-related products are AI Apply and browser-agent integrations. Unified MCP is a first-party product with 22,566 callable tools across all integrations, a URL per connection carrying a token scoped to that one connection, US, EU and AU regions, and personal information stripped before results reach the model.

How does Kombo compare to Finch?

Both are HR-vertical unified APIs on sync-and-store architectures. Finch is US-focused with deep US payroll coverage and per-connection pricing. Kombo has offices in New York and Berlin, prices per customer, and covers a broader future-of-work scope including ATS, assessment and LMS. See Finch vs. Unified.to for that comparison.

Start your 30-day free trial of Unified.to or talk to our team to see how the architecture fits your product.

Written by Mallory Greene

Mallory Greene is Head of Marketing at Unified.to. She writes about integration infrastructure, unified APIs, and MCP for technical teams. Based in Toronto.