How Unified.to supports 500+ integrations without sacrificing depth
June 29, 2026
Unified.to now supports more than 500 integrations across 30 categories. The live count is on our integrations page, and it moves up weekly.
A catalog count is easy to inflate and tells you nothing on its own about what each integration does once you build on it. So the number isn't the interesting part. What it implies is.
Our competitors take a sharper line. Their comparison content lands on one recurring claim: that we can offer this many integrations because the depth within each one is shallow. Breadth, the argument goes, is paid for in depth.
That inference is built on their older architecture, not our next-gen architecture.
In a sync-and-store design pattern, a large catalog does come at the cost of depth: every integration is a pipeline to build and maintain, and the data models stay shallow to keep that manageable at scale. So when a competitor sees our count, they assume the same tradeoff applies to us. It doesn't.
The reason we can offer this many integrations and this many categories and go deep on them is the same reason they can't follow: our architecture is different.
Four generations of integration architecture
Integration technology has moved through distinct generations, and each one traded something away.
→ ETL came first, decades ago (1980s). It extracts data from one database, transforms it, and loads it into another, in scheduled batches. It was never built for live data.
→ iPaaS (Boomi, Paragon, Ampersand) arrived with SaaS (circa 2005) and was the first to connect SaaS platforms to each other, but it kept the batch-processing model underneath. It just replaced databases with SaaS platforms in the cloud and was still bounded by scheduled syncs.
→ First-generation unified APIs (Merge, Kombo, Apideck) were the real change: a shared category data model with common objects and a common API interface, so you stopped writing per-vendor code for every connection. But the normalization was partial.
Core fields are standardized; vendor-specific fields, edge cases, and complex relationships leak through, and you handle those with per-vendor logic of your own. They all also inherited the old plumbing underneath, a sync-and-store model where data is copied into the vendor's database, refreshed on a schedule, and served to you from that cached copy.
That leaves two gaps. Reads are only as fresh as the last sync (usually 24 hours), and your customer's data sits at rest in someone else's infrastructure (and creates an unmanaged security attack vector). And because normalization stops at the common fields, the integration is only partly standardized: the surface looks consistent, but the quirks still reach your code.
→ Unified.to is the next generation, a real-time unified API. Every read and write routes to the source at request time, with no data stored at rest, so the data is current and stays out of your compliance scope.
And the unification runs through the whole stack, not just the data model: consistent API semantics, normalized authorization and scopes, and one event model across every category. Related data is unified into well-designed objects rather than scattered across separate ones, so a single call returns a complete record.
None of that gets thinner as the catalog grows, because none of it is rebuilt per integration. Breadth and depth aren't competing for the same resource.
Why the catalog can grow without thinning out
The competitor claim assumes the old cost structure, where every integration is a data pipeline someone builds, syncs, and maintains. Under that model, a bigger catalog is a bigger maintenance surface, and the work of adding the next connector competes with the work of supporting the last one.
Pass-through changes the shape of that cost. Reads hit the source live, so we don't maintain a per-vendor copy of your customer's records.
The cross-cutting parts that usually make each integration expensive, authorization, change detection, rate-limit handling, normalization, are handled once at the platform layer rather than rebuilt per connector.
Adding a new integration is mostly mapping a new source onto models and patterns that already exist, not standing up new infrastructure for it. That's why the catalog can grow weekly without the per-integration experience getting thinner.
'Unification' is not 'merging'
Take ATS integrations as the example; When a platform models every related concept as its own first-class object, screening questions, tags, interviews, offers, and rejections each standing alone, a single "show me this application" view becomes several API calls your code stitches together. The object list looks comprehensive in a sales comparison. You pay for it in the integration.
We embed related data inside the object it belongs to instead: screening questions and tags on the job, interviews and offers and rejections on the application, notes in activities. One call returns the enriched object rather than a join you assemble yourself by calling multiple 'unified' API endpoints. Fewer calls, less orchestration, less to maintain as each underlying API shifts. That's unification. Taking every vendor object and merging them together as separate first-class objects is just merging, and it pushes the assembly work onto you.
The principle isn't specific to recruiting. A well-designed Stripe payment intent hands you one object with the charge, status, and next action, instead of a session, a verification call, and each downstream step on its own. Same data, far less assembly.
The cost of the many-objects path doesn't show up on day one. It shows up as build time, latency, and the maintenance load of every extra call, easy to under-weight when AI coding tools make the first version feel fast, and still real in production. When agents scaffold the integration, bad unification still creates technical debt; you just have less visibility into it. You're borrowing from your future.
Deep doesn't mean rigid
A fair critique of any normalized model is that it can hide provider-specific fields and edge cases. We treat that as a design requirement, not a gap. Anything outside the unified shape stays reachable: include raw in your request and you get the original, unmodified provider fields back, and you can write provider-specific fields the same way. The fields that are genuinely expensive upstream, the ones that cost an extra source call per record, are handled through slow-field controls, so you choose completeness or latency per request instead of paying for it everywhere by default.
The same standardization runs through authorization. Unified permission scopes map to each vendor's specific scopes, with token refresh and tenant-scoped connections handled for you. But you can always override the standard permission scopes for your use-case. And your application tracks a single persistent artifact, the connection ID, rather than a sprawl of per-vendor tokens and objects. One ID maps to your end-user, and the integration complexity sits behind it.
One event model, live or polled
Real-time isn't only about on-demand reads. Most SaaS APIs don't offer native webhooks, so the old answer was to build polling and retry logic yourself, per integration.
At Unified, we virtualized real-time webhooks and support them on almost 100% of our integrations, regardless if the source system has real webhooks. We detect changes at the source on an interval you configure, as frequent as every minute, and deliver events to your endpoint with the changed records in the payload, so there's usually no follow-up fetch and no need to handle rate-limit back-off strategies. When a source does offer native webhooks, we pass those through on the same interface. Your code consumes one event model and never branches on which delivery path an integration uses.
This is not a batch sync that finishes and sends a "something changed" notification, leaving you to go fetch the records. Events carry the data. That's the difference between an event-driven surface and a sync-notification one.
Transparency about integration support
The catalog grows by customer demand, and what each integration supports varies by what the underlying API permits. What doesn't vary is that you can see it before you commit. Our published capability matrices show readable fields, writable fields, and events per integration, so you evaluate against the systems your customers actually run rather than finding the gaps in month three.
The count is evidence, not the argument
Anyone can generate a long list of integrations now. Coding agents have made standing up a connector close to free. The hard part was never building one; it's keeping it working as the API underneath it changes, and absorbing that drift across the whole catalog so it never becomes your problem.
That's the work the number represents: 500 integrations that return live data, hold a consistent shape, and stay current, backed by testing against both synthetic data and real provider sandboxes.
Breadth and depth were a first-generation tradeoff. They stopped being one when the architecture changed. 500 integrations across 30 categories isn't us choosing breadth. It's what a real-time, fully unified architecture produces when breadth no longer costs depth.