Kombo vs. Unified.to: Sync-and-Store vs. Real-Time Pass-Through (2026)

June 4, 2025

Updated June 2026

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

Kombo syncs a copy of your customers' HR data into its own database and serves your API calls from that store. Unified.to executes every call against the source system at request time and stores no business data at rest. That single decision — store a copy versus reach the source live — drives the differences that actually matter: data freshness, compliance footprint, how much of each source API you can reach, and how the platform behaves under an AI agent.

This is the comparison that counts, and it isn't breadth versus depth. Both platforms model HR systems in detail. 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.

The architectural difference

Kombo is sync-and-store. When a customer connects an HR or ATS system, Kombo pulls their records into its own database and keeps them updated on a schedule. Your API calls read from that copy. A Passthrough API sits on top of the store for cases the common model doesn't cover.

Unified.to is pass-through. Each 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, with customer-managed-key options from the Pro tier up.

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 normalized schema on top, and the storage and staleness that come with it. It's the pattern Kombo, Merge, Apideck, and Finch are all built on. The next generation keeps the unified schema but drops the store: requests hit the source live, nothing rests in vendor infrastructure, and freshness isn't a sync setting. Sync-and-store and pass-through aren't better and worse versions of one architecture — they're the before and after of a generational shift in how the problem gets solved.

You can read the difference directly off Kombo's own data model. Every record they return carries a changed_at timestamp and a remote_deleted_at field, and their docs note that records are marked deleted "when Kombo can't retrieve them from the remote system anymore," with entries anonymized 14 days after they disappear. Those fields exist because the data lives in Kombo's store and has to be reconciled against the source over time. A pass-through layer has nothing to reconcile — there's no stored copy to drift.

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

What "pass-through" buys 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 at its last poll — by default every three hours for systems without native webhooks, and faster only on higher tiers. When Unified.to serves a read, the call hits 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 "up to three hours ago" is the difference between showing correct data and showing stale data.

No candidate or employee PII sits in a third party's database. Sync-and-store means your customers' HR data — which is PII, often in regulated categories — is persisted in the vendor's infrastructure, with the security and compliance obligations that creates. Pass-through means that data never comes to rest outside the source system and your own product. For teams whose security narrative to customers 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 — hours, for a large HRIS instance — and an ongoing reconciliation loop that can lag or drift. Pass-through has no warm-up and no drift: the first call works and every call reflects the source.

You're not limited to the normalized schema

The usual objection to a normalized API is that the common model can't cover every field of every system, so you lose access to the long tail. Unified.to answers this at the architecture level, two ways:

• Raw fields on every object. Request raw in the fields parameter and the response includes the original source payload alongside the normalized object, including platform-specific fields that aren't in the common model. You can pull specific custom fields by name (raw.customerSegment) and write platform-specific attributes back by sending them inside a raw object in the request body. The normalized schema is the default, not the ceiling.
• The Passthrough API for anything unmodeled. 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 auth and routing and returns the native response. Any method, any payload — the full surface of the underlying API, through your existing connection.

Both mechanisms run live through the same pass-through path, so reaching beyond the schema doesn't move you onto a different, staler code path. Kombo offers a comparable escape hatch — a Passthrough API and per-system remote_fields — so this isn't a capability only one platform has. The difference is what's underneath it: with Unified.to, both the normalized call and the raw/Passthrough call hit the source live; with Kombo, the normalized read comes from the store.

Where Kombo's architecture is the better fit

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

• Fast repeated reads when staleness is acceptable. For workloads that query the same records many times and don't need them current to the second — historical reporting, batch analytics, internal dashboards over employee data — serving from a store can avoid repeated round-trips to the source. Sync-and-store is built for exactly that access pattern.
• Deep European HR connector coverage. Kombo lists more EU-specific HR and ATS connectors — Personio, PayFit, Softgarden, AFAS, Cegid, Kenjo, d.vinci, Factorial — than a horizontal platform typically carries. If your customers run those systems, that connector list is a concrete advantage in that regional slice.
• ISO 27001 certification. Both platforms hold SOC 2 Type II and comply with HIPAA and GDPR, and both offer regional data residency — Kombo across EU and US, Unified.to across US, EU, and Australia. Kombo's one compliance edge is ISO 27001, which Unified.to does not currently hold. For European enterprise procurement that requires ISO 27001 specifically, that's a real differentiator. (Note the inverse on data residency: Kombo isolates PII by region because it stores it; Unified.to's no-storage architecture means there's no customer PII persisted in any region to isolate.)
• 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. That decouples cost from call volume — useful if you have many customers each generating heavy usage, since you're not metered on calls. The tradeoff is that cost scales with customer count rather than usage.
• Hands-on support. G2 reviewers consistently praise Kombo's support — responsive, available over Slack and Teams, with white-glove onboarding for complex systems like SAP SuccessFactors and Workday.

If your product is HR-tech first, your customers are concentrated in European HR systems, and your access pattern is frequent reads over cached records, Kombo's architecture is built for exactly that. The trade-off you're accepting in return is that HR PII lives in Kombo's infrastructure and reads are as fresh as the last sync.

Coverage

Unified.to covers the same future-of-work categories Kombo does — HRIS, ATS, LMS, and Assessment & Background Check (plus payroll and identity/directory) — and then 25 more on top, including CRM, Accounting, Marketing Automation, Messaging, Calendar & Meetings, Ticketing, File Storage, Enrichment, and AI Tooling: 29+ categories across 470+ integrations in total. Kombo's catalog is the four future-of-work categories, with the EU HR connector depth noted above, across 250+ integrations. The difference isn't that Unified.to trades HR coverage for breadth — it's that Kombo's four categories are a subset of what Unified.to already covers.

The point isn't a connector-count contest. It's that every category Unified.to covers runs on the same pass-through architecture, so HR, CRM, accounting, and messaging all behave the same way: live reads, no stored copy, raw and Passthrough access to each source. A product that needs HR plus other categories integrates one platform 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.

Unified.to also publishes a per-integration capability matrix: which objects, fields, and webhooks are supported for each system, visible before you commit. Kombo's coverage is enumerable from its docs but isn't published as a single matrix.

AI and MCP

The architecture difference shows up most sharply under an AI agent. An agent reasoning over a stored copy is reasoning over data that's as fresh as the last sync; an agent over a pass-through layer reads the source at the moment it acts.

Unified MCP is a first-party flagship product: multi-region endpoints (US/EU/AU), 32,666 callable tools across 470+ integrations (6,904 of them normalized; the rest passthrough access) through MCP schemas, and bi-directional read and write so agents can query records and trigger actions across HR plus every other category. It's compatible with Anthropic, OpenAI, Google Gemini, Cohere, x.ai Grok, and Groq.

AI integrations work through Kombo's standard REST APIs into your own agent framework.

Security and compliance

Pricing

Kombo is sales-led across all tiers (Start, Scale, Enterprise) with no public dollar amounts — every tier shows "Get a Demo" — on a platform-fee-plus-per-customer model with unlimited calls per connection (their per-customer fee tiers down as you scale).

Unified.to publishes entry pricing across four tiers: Grow at $750/month for 750,000 calls; Pro at $1,250/month for 1.25M calls, adding SAML SSO, customer-managed secret storage, and IP allowlisting; 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 and all 29+ unified APIs.

The models decouple cost from different things, and they pull in opposite directions as you grow. With a per-customer or per-connection model, your cost rises with every customer you onboard and every integration they connect — adoption itself raises the bill, and teams on those models often cap how many integrations they offer to control it. With Unified.to's usage-based model, customers and connections are unlimited; cost tracks API activity, 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 needs discipline is genuinely heavy read volume — high-frequency or analytical workloads that would run up calls. The structural answer isn't a different pricing model; it's Database Sync (included on all plans): stream normalized records to your own Postgres, MongoDB, or MySQL for analytics and high-volume cached reads, and reserve live API calls for the data that has to be current. High-volume reads happen outside the per-call quota, and the data lives in your infrastructure, not Unified.to's. So the honest comparison is: per-connection pricing is easy to model but taxes growth and integration depth; usage-based rewards both, 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 — the published rates on both sides will show you the curve.

Customer spotlight: Humi

Humi is a Canadian HR platform serving thousands of businesses across HRIS, payroll, and benefits. As their integration catalog 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 their team estimated at 7+ years natively — using the HR API plus passthrough access for vendor-specific edge cases, all behind one API surface.

Humi is the relevant data point for this comparison precisely because it's an HR-first product that chose a multi-category pass-through platform. When integrations span employee data plus the other workflows around it — CRM for sales handoffs, accounting for payroll exports, calendar for onboarding — one platform with one architecture beat stitching a vertical specialist to separate vendors.

How to choose

Kombo fits if your customers run EU-specific HR systems where Kombo's connector list goes further; ISO 27001 plus in-region data isolation is a procurement requirement; your access pattern is frequent reads over cached HR data (dashboards, reporting, analytics) where a stored copy is the point; 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 on one platform and one architecture; you're building AI agents that must act on current data through a managed MCP layer; or you want customer-managed secrets, SAML SSO without an Enterprise contract, and self-serve entry pricing.

Frequently asked questions

Is Kombo a unified API? Yes — for future-of-work systems. Kombo is a unified API for HRIS, ATS, Payroll, LMS, and Assessment, abstracting Personio, BambooHR, Workday, Greenhouse, Lever, and others behind common models per category. The difference from horizontal unified APIs is scope: Kombo's is HR-only; Unified.to's spans 29+ categories including HR.

Does Unified.to cover the same HR and ATS systems as Kombo? 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 on the live pass-through architecture. Kombo lists more EU-specific HR connectors (PayFit, Softgarden, Factorial, AFAS, Cegid); if your customers run those, check both connector lists against your specific systems.

What's the practical difference between sync-and-store and pass-through? Sync-and-store keeps a copy of your customers' data in the vendor's database and serves reads from it — fast for repeated queries, but as fresh as the last sync and resident in vendor infrastructure. Pass-through reaches the source on every call — current data, no business data at rest — at the cost of a live round-trip per request. Kombo is the former; Unified.to is the latter.

Does the normalized model limit which fields I can reach? No. On Unified.to, the raw envelope returns the original source payload alongside the normalized object and accepts platform-specific fields on writes, and the Passthrough API reaches any unmodeled endpoint live. The common model is the default, not the ceiling.

Does Kombo have an MCP server? Not as of mid-2026. AI integrations run through its REST APIs into your own framework. Unified MCP is a first-party product with US/EU/AU endpoints and 32,666 callable tools across all integrations (6,904 normalized, the rest passthrough).

How does Kombo compare to Finch? Both are single-vertical HR unified APIs on sync-and-store architectures. Finch is US-centric with deep US payroll coverage and per-connection pricing; Kombo is EU-rooted with deep European HR coverage, per-customer pricing, and broader future-of-work scope. 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 coverage and architecture fit your product.