Pass-Through vs. Sync-Based Unified APIs: Architecture Trade-offs in 2026

A pass-through unified API executes requests directly against the source system in real time. A sync-based unified API copies third-party data into its own database and serves reads from that stored replica.

As of October 2026, Unified.to, Apideck and Truto read from the source system at request time by default; Merge, Kombo, Rutter, Codat and Finch store a synced copy and serve normalized reads from it; Nango and Paragon do both. Of the pass-through platforms, Unified.to stores no customer records for any integration and logs operational metadata only, where Apideck's request logs capture full bodies by default and Truto offers opt-in stores.

One useful way to think about the difference: a pass-through platform acts as an execution layer, and a sync-based platform acts as a data layer. Problems tend to arise when a team expects one to behave like the other. Both can provide the same endpoints, but they produce very different behaviour once your product is in production.

Key takeaways

• Pass-through unified APIs execute requests directly against source systems in real time; sync-based unified APIs serve data from a stored replica.
• The core trade-off is current-state accuracy versus fast cached reads, not one being universally "better."
• Pass-through fits workflows, automation, read-after-write consistency, and action-taking AI agents. Sync-based fits analytics, bulk queries, historical reporting, and rate-limit-heavy sources.
• Most platforms blur the line at the edges (selective caching, on-demand fetch, hybrid eventing). The distinction is about the primary model, not absolute behaviour.
• This decision shapes product behaviour, so choose the model that matches what your product actually needs to do.

Why does the pass-through vs sync-based distinction matter?

The distinction decides whether your product reflects current state: two platforms can both return data from /crm/contacts, but one returns live data from the source system and the other returns a cached copy from a background sync.

That difference also affects whether workflows execute correctly, whether users trust what they see, and whether AI systems produce accurate outputs.

This is not an implementation detail. It defines how your product behaves.

What is a pass-through unified API?

A pass-through unified API is a real-time execution layer. When your application makes a request:

1. the platform authenticates the request
2. retrieves connection credentials
3. translates the unified request into the source's format
4. calls the upstream API directly
5. normalizes the response in memory
6. returns the result immediately

No customer payload data is stored as a system of record. In practice, reads come directly from the source system, writes go directly to the source system, responses reflect current state, transformations happen at request time, and latency depends on the upstream API. This model prioritizes correctness and real-time behaviour.

A practical caveat: even pass-through platforms typically hold some operational data (rate-limit counters, pagination cursors, encrypted credentials, request logs). "Pass-through" describes where the system of record lives (the source), not a claim that nothing is ever held in memory or logged.

Pass-through architecture is not the same thing as a Passthrough API. Unified.to's Passthrough API sends a request to a vendor's own endpoint through an existing connection, for fields or calls outside the unified model (how to use it). Pass-through architecture describes where a platform reads data from; sync-based platforms such as Merge offer passthrough calls too.

What is a sync-based unified API?

A sync-based unified API uses a replication model. Instead of fetching data on demand, the platform polls upstream APIs on a schedule, retrieves data in batches, normalizes it, stores it in its own database, and serves API responses from that stored copy.

In practice, reads come from the platform's database, writes still go to the source system, how current the data is depends on sync frequency, and background jobs manage pagination, retries, and rate limits. This model prioritizes speed and availability for reads.

How do pass-through and sync-based unified APIs compare?

What are the trade-offs between pass-through and sync-based?

The core trade-off is current-state accuracy versus fast cached reads: pass-through gives current data, read-after-write consistency and a smaller data-at-rest footprint, while sync-based gives faster reads, bulk and historical queries, and continued reads when the source is down.

Current data vs. speed

Sync-based systems are faster for reads because they query a local database, but the data may be outdated. Pass-through systems are slower because they depend on upstream APIs, but the data is accurate at the moment of the request. The real question is not speed. It is whether your product needs current state.

Where sync-based genuinely wins

Sync-based isn't just "acceptable" for some workloads; it's objectively the better fit for several:

• Bulk queries across large datasets. Generating a financial report across thousands of records is often infeasible in a pass-through model due to pagination and per-source rate limits, but trivial against a replicated dataset.
• Cross-object joins that upstream APIs don't support natively.
• Historical snapshots for point-in-time reporting.
• Rate-limit-heavy sources (common in accounting and HR), where repeated live calls hit ceilings quickly.

If your product is reporting- or analytics-led, a stored replica isn't a compromise; it's the right architecture.

Read-after-write consistency

This is where many teams run into problems. In a pass-through model, you update a record, read it immediately, and see the updated value. In a sync-based model, you update a record, the sync hasn't run yet, and you read stale data. That inconsistency surfaces in user interfaces, approval workflows, and automation logic.

Event delivery and product behaviour

Sync-based platforms typically emit events after a sync completes, which introduces delay and often requires a follow-up API call to fetch the updated data. Pass-through platforms differ here. Unified.to's virtual webhooks check for changes as often as every minute on paid plans, on supported integrations, and put the changed records in the event, so no follow-up fetch is needed. Apideck's virtual webhooks poll about every 24 hours and send the entity ID and a URL to fetch it (as of 8 October 2026). For a vendor-by-vendor view, see which unified APIs support virtual webhooks vs sync-based notifications. This changes how you design product features: whether your system reacts when the next check or source event arrives, or after the next sync completes.

Compliance and data storage

Sync-based platforms store customer data, which expands audit scope, data residency requirements, and breach surface area. Pass-through platforms avoid storing payload data, which reduces compliance overhead, vendor risk, and duplication of sensitive data.

To be balanced: pass-through isn't zero-risk. It still handles sensitive data in transit, and logging, retries, and debugging can still create exposure points that belong in a security review. Some enterprises also prefer controlled, audited storage over repeated external calls. The advantage is a smaller data-at-rest footprint, not the elimination of data handling.

To check what a given vendor stores, see Why Unified APIs Shouldn't Store Your Customer Data. For building webhooks and residency controls without a stored copy, see best practices for webhooks and data residency controls, and for Unified.to's own controls, Unified API Security.

Behaviour under failure

Sync-based systems can keep serving stale data if the upstream API is unavailable. Pass-through systems reflect upstream availability directly: if the source API is down, requests fail. This is a genuine trade-off between availability and correctness, and different products weigh it differently.

AI and real-time systems

"AI-ready" is an overused claim, so it's worth being precise about where architecture actually matters.

AI systems that take actions (agents, copilots executing writes, synchronous read-reason-write loops) depend on current state. Feeding them stale data produces incorrect actions on a version of reality that no longer exists.

AI systems that analyze or summarize (RAG pipelines, reporting copilots) can often tolerate slightly stale but well-structured data, and sometimes prefer a denormalized replica for query performance.

So the architecture question for AI isn't "real-time or not"; it's "is this system acting on state, or reasoning over it?" Action-taking aligns with pass-through; analysis can live comfortably on sync.

Which unified APIs fetch data live, and which cache it?

Of the ten unified APIs compared here, three fetch live by default, five serve reads from a stored copy and two combine both. Most blur the edges, so these are primary models, checked against each vendor's own documentation on the dates shown.

Pass-through / real-time execution (as of 8 October 2026): Unified.to, Apideck, Truto.

• Unified.to routes every call to the source system and stores no customer records for any integration; its logs record endpoint, timing and status, never payloads.
• Apideck queries the connected system directly and says it does not persist business records.
• Apideck's API Logs page says full request and response bodies are captured, with logging on by default.
• Truto's unified and proxy calls hit the vendor live by default; its opt-in RapidBridge sync jobs and SuperQuery store are the exception.

Sync-and-store: Merge, Kombo, Rutter, Codat, Finch. These store a synced copy and serve normalized reads from it; most also offer a narrower request-time path.

• Merge keeps synced data and credentials until you delete them, and goes to the source for Passthrough (Professional and Enterprise) and file contents (as of 1 October 2026).
• Kombo reads from its own database, synced at regular intervals; the Kombo comparison covers what that means in practice.
• Rutter says that most of the time its data is cached (as of 8 October 2026).
• Codat serves reads from its cache and publishes no retention period (as of 8 October 2026).
• Finch responses return the most recent successful sync, with live Request Forwarding on Pro and Premier (as of 8 October 2026).

Hybrid / infrastructure-oriented (as of 8 October 2026): Nango, Paragon. These give you more control over execution logic, at the cost of more implementation work.

• On Nango Cloud, synced records sit in Nango's US records cache (payloads pruned 30 days after their last update, records deleted after 60 days without a sync run).
• Nango actions and the proxy call the provider at request time; only Enterprise BYOC or self-managed deployments keep data in your own cloud.
• Paragon pairs a stored Managed Sync replica on its cloud (US and EU data centres; no retention period published) with request-time ActionKit and Proxy calls.
• Keeping Paragon synced data in your own infrastructure requires its Enterprise on-premise deployment.

This classification is more useful than feature lists, because it predicts how the system behaves under load, failure, and write-heavy workflows, but verify any given vendor's current model against its own documentation, since several support more than one pattern.

Why do unified API vendors with the same architecture still differ?

Unified API vendors with the same architecture still differ because the product built on top of it varies: even among pass-through platforms, schema depth, event delivery design, support for custom fields and objects, passthrough flexibility, category breadth, pricing model and AI/agent support all differ.

For example, Apideck pairs live reads with Vault, its embedded integrations marketplace. Unified.to adds change events that carry the changed records on supported integrations, Database Sync into your own database (Grow, Pro and Scale, for objects with native or virtual webhooks), and an MCP server across the same categories. The architecture defines the baseline; the product surface defines what you can build.

Why do some unified API platforms use a hybrid model?

Some unified API platforms use a hybrid model because no single architecture suits both request-time execution and high-volume querying, so they combine request-time API calls with scheduled storage, usually to support analytics, repeated queries over large datasets, or historical reporting.

Hybrid models don't eliminate the trade-offs; they combine them. Part of your product runs on live data, part on stored data, which creates two sources of truth. You then have to reason about when data was last synced, whether a given response is live or stored, and how inconsistencies are resolved. That's manageable for reporting features and problematic for automation or decision logic where read-after-write consistency matters.

The pragmatic takeaway: storage can exist, but it should be intentional, controlled, and separate from your execution layer, not silently mixed into it.

Should you choose a pass-through or sync-based unified API?

Choose pass-through if your product depends on current state, you're building workflows or automation, read-after-write consistency matters, you're building action-taking AI features, or you want to reduce compliance scope.

Choose sync-based if you need fast repeated reads, you're building dashboards or reporting, some data staleness is acceptable, or you want insulation from upstream outages.

Choose hybrid if you need both real-time accuracy and high-volume querying, and you're prepared to manage execution and storage as deliberately separate layers.

Most teams will use elements of both. The discipline is being deliberate about where data is stored and why, rather than discovering the boundary in production.

Unified.to is built around the pass-through model: requests route directly to source APIs at request time, no customer records are held at rest (connection credentials and operational metadata are encrypted at rest), and native and virtual webhooks provide event-driven behaviour on supported integrations, with custom fields, objects, and raw passthrough available across plans. For teams whose products depend on current state, it's the execution layer that decision points to.

→ Start your 30-day free trial

→ Book a demo

Written by Mallory Greene.

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